2026년 8월 10일 IETF가 RFC 10024를 발행했다. 통신을 시작할 때 양쪽이 암호 열쇠를 나눠 갖는 절차를 규정한 TLS 1.3에서, 기존 타원곡선 방식과 포스트양자 알고리즘 ML-KEM을 함께 쓰는 조합 세 가지를 정한 문서다. 이 문서는 그전까지 등록돼 있던 표준화 이전 임시 항목을 폐기하고 그 자리를 대신한다.
무엇이 발행됐나
문서의 정식 제목은 "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3"이다. 저자는 K. Kwiatkowski, P. Kampanakis, B. E. Westerbaan, D. Stebila 네 사람이고, IETF 스트림에서 나왔다. RFC Editor의 정보 페이지는 이 문서의 상태를 "This is an Internet Standards Track document."라고 적고 있다. 즉 표준화 트랙 문서다.
1장 도입에 따르면 ML-KEM은 미국 NIST가 FIPS 203으로 규정한 키 캡슐화 메커니즘이고, 전통 키 교환과 차세대 키 교환을 결합하는 일반적인 틀은 RFC 9954가 제공한다. RFC 10024는 그 틀을 ML-KEM에 적용하고, 결합된 그룹에 쓸 코드포인트를 지정하는 역할을 맡는다. RFC 9954는 2026년 7월 15일 발행된 정보성(Informational) 문서이며, 정보 페이지에는 이 문서를 폐기하거나 갱신한 후속 RFC가 표시돼 있지 않다.
'하이브리드'가 뜻하는 것
3장 용어 정의는 세 단어를 구분한다. '전통(traditional)' 알고리즘은 이미 널리 쓰이는 것으로, Curve25519·P-256·P-384를 쓰는 ECDHE가 여기 속한다. '차세대(next-generation)'는 아직 널리 채택되지 않은 것으로, ML-KEM이 여기 속한다. '하이브리드'는 여러 알고리즘을 동시에 쓰고 그 결과를 결합해, 적어도 하나가 안전하게 남아 있으면 전체가 안전하도록 만드는 방식을 가리킨다.
결합 방법 자체는 단순하다. 4.1~4.3절이 규정하는 대로, 클라이언트가 보내는 값은 ML-KEM 캡슐화 키와 타원곡선 임시 공개값을 이어붙인 것이고, 서버가 보내는 값은 ML-KEM 암호문과 서버 쪽 임시 공개값을 이어붙인 것이다. 최종 공유 비밀도 두 알고리즘이 각각 만든 공유 비밀을 이어붙여 만든다.
세 가지 조합과 전송되는 크기
7장 IANA 고려사항이 지정한 코드포인트와 4.1~4.3절이 밝힌 바이트 크기는 다음과 같다.
|
이름 |
코드포인트 |
클라이언트 값 |
서버 값 |
공유 비밀 |
|
X25519MLKEM768 |
4588 (0x11EC) |
1216바이트 |
1120바이트 |
64바이트 |
|
SecP256r1MLKEM768 |
4587 (0x11EB) |
1249바이트 |
1153바이트 |
64바이트 |
|
SecP384r1MLKEM1024 |
4589 (0x11ED) |
1665바이트 |
1665바이트 |
80바이트 |
2장은 세 조합의 쓰임새를 나눠 설명한다. X25519MLKEM768은 널리 배포된 X25519를 쓰기 때문에 가장 실용적인 선택으로 제시된다. SecP256r1MLKEM768은 두 공유 비밀이 모두 FIPS 승인 방식으로 만들어져야 하는 경우를 위한 것이다. SecP384r1MLKEM1024는 보안 여유를 더 두려는 고보안 환경을 겨냥한다.
IANA의 TLS Supported Groups 등록부(2026년 8월 10일 갱신 표시)에서 확인하면, 세 항목 모두 DTLS 사용이 가능(Y)으로 표시돼 있고 Recommended 열은 X25519MLKEM768만 Y, 나머지 둘은 N이다. 같은 등록부에서 25497번 X25519Kyber768Draft00과 25498번 SecP256r1Kyber768Draft00은 이름 뒤에 (OBSOLETE)가 붙고, 비고란에 "표준화 이전 판인 Kyber768"이며 RFC 10024가 이를 폐기했다고 적혀 있다.
규제 맥락과 보안상 단서
5장은 '규제 맥락(Regulatory Context)'이라는 제목으로, 결합 방식이 NIST 지침과 어떻게 맞물리는지를 다룬다. NIST SP 800-56C 개정2판과 SP 800-227을 인용하며, 두 공유 비밀을 이어붙일 때의 순서가 그룹마다 다른 이유를 어느 쪽 구현이 인증 대상이 되는지와 연결해 설명한다. 실제로 4.1~4.3절을 보면 X25519 계열은 ML-KEM 값이 앞에 오고, secp256r1·secp384r1 계열은 타원곡선 값이 앞에 온다.
6장 보안 고려사항은 RFC 9954의 보안 고려사항이 이 문서의 방식에도 그대로 적용된다고 밝힌다. 그중 한 가지로, ML-KEM에서는 캡슐화에 쓴 난수가 복호 과정에서 다시 드러나기 때문에 난수 생성기의 상태가 능동적 공격자에게 노출될 여지가 있다는 점을 지적한다. 부채널 공격에 대한 저항, 특히 원격 공격자가 이용할 수 있는 경로에 대한 저항을 구현에서 우선하라고 권고한다.
이 글이 말하지 않는 것
이 글은 규격 문서의 내용만 다룬다. 실제로 이 조합들이 인터넷 트래픽에서 얼마나 쓰이고 있는지, 접속 지연이나 서버 부하가 얼마나 늘어나는지는 RFC 10024가 다루는 범위가 아니며 이 글도 수치를 제시하지 않는다. IANA 등록부의 Recommended 열이 정확히 어떤 절차와 기준으로 정해지는지도 다루지 않았다.
표준화 트랙 문서로 발행됐다는 사실이 안전성 증명은 아니다. NIST의 FIPS 203 발행 페이지에 실린 초록은 ML-KEM의 안전성이 Module Learning with Errors 문제의 계산적 난이도에 연결돼 있으며 양자컴퓨터를 가진 공격자에 대해서도 안전하다고 '믿어진다'고 서술한다. 증명이 아니라 가정에 근거한 서술이다. 또한 같은 페이지에는 2025년 11월 17일자 안내문이 붙어 있는데, 향후 개정판에서 바로잡을 사안이 있다고 알리고 있다. 해당 안내문은 구체적 내용을 별도의 정오표 문서로 안내한다.
출처
- RFC Editor, RFC 10024 정보 페이지(제목·저자·상태), 2026년 8월 10일
- RFC Editor, RFC 10024 "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3" 본문(HTML), 2026년 8월 10일
- RFC Editor, RFC 10024 본문(텍스트판), 2026년 8월 10일
- IETF Datatracker, RFC 10024 본문
- RFC Editor, RFC 9954 "Hybrid Key Exchange in TLS 1.3" 정보 페이지, 2026년 7월 15일
- IANA, Transport Layer Security (TLS) Parameters(등록부 갱신 표시 2026년 8월 10일)
- IANA, TLS Supported Groups 등록부(CSV)
- NIST, FIPS 203 "Module-Lattice-Based Key-Encapsulation Mechanism Standard" 발행 페이지, 2024년 8월 13일