비밀 NSA 문건에 따르면, NSA는 1970년대에 DES가 해킹하기에 "충분히 약하다"는 것을 알고 있었음에도 불구하고 "경쟁자들을 몰아내기" 위해 DES를 밀어붙였습니다. 그동안 NSA는 공개적으로는 DES를 사용할 것이라고 주장했습니다. NSA는 1990년대에 수출법 예외 조항을 사용하여 RC4와 RSA-512를 공고히 했으며, 이는 수십 년 동안 보안 문제를 야기했습니다. 2000년대에 NSA는 난수 생성기 (RNG) 표준을 방해하고 기업들이 이를 배포하도록 돈을 지불했습니다. 2010년대에 이르러 NSA는 "소비자와 기타 적대 세력"이 "시스템의 보안이 온전하게 유지되고 있다"고 믿는 동안, 시스템을 "착취 가능하게" 만들기 위해 표준 및 기타 시스템을 "비밀리에 영향력을 행사하거나/또는 공개적으로 활용"하는 데 연간 2억 5천만 달러의 예산을 사용했습니다.

IETF의 이중적 표현(doublespeak)으로 "최종 호출 (last call)"이라 명명된 현재 IETF TLS 작업 그룹 (WG)의 투표는, TLS 내 단독 ML-KEM에 대한 IETF RFC를 추진하려는 NSA의 노골적인 압박에 관한 것입니다. RFC를 발행한다는 것은 TLS 내 단독 ML-KEM에 대한 IETF의 승인을 발행하는 것을 의미합니다. TLS 내 단독 ML-KEM 및 단독 ML-DSA에 대한 RFC 이후의 다음 단계는, 아마도 NSA가 단독 ML-KEM 및 단독 ML-DSA의 광범위한 배포를 장려하기 위해 계속해서 돈을 쓰는 것이 될 것입니다. 이는 규격 자체의 보안 결함에 대한 위험은 말할 것도 없고, ML-KEM 소프트웨어 버그와 ML-DSA 소프트웨어 버그의 예측 가능한 유입 때문에 용서받을 수 없는 보안 재앙이 될 것입니다.

IETF 규칙은 참여가 "모두에게 열려 있다"고 규정합니다. 단독 ML-KEM에 대한 이번 투표는 "2026-07-08에 종료된다"고 명시되어 있습니다. 이것이 8일에 여전히 투표를 제출할 수 있다는 의미인지, 혹은 어떤 시간대를 말하는 것인지 알 수 없으나, 분명 끝이 다가오고 있습니다.

IETF는 또한 작업 그룹 (WG)의 모든 "공식적인 업무"가 WG의 메일링 리스트에서 수행된다고 말합니다. 이 특정 투표에 대해, 점점 더 많은 사람들(현재까지 60명)로부터 반대 메시지가 메일링 리스트에 나타나고 있습니다. 찬성론자들은 그 숫자가 늘어나는 것을 막기 위해, 즉 당신이 목소리를 내는 것을 주저하게 만들기 위해 그들이 생각할 수 있는 모든 논거를 동원하고 있습니다. 예를 들어:

2026년 7월 1일,
"ncsc.gov.uk"의 "Michael P"
(즉, NSA의 영국 파트너인 GCHQ 소속)는
"보안 불감증에 대한 추측성 주장"이
"ML-KEM으로의 전환을 저해할 잠재적 가능성"이 있다고
썼습니다.
어쩌면 당신은 이것을 보고 이렇게 생각할지도 모릅니다.
'와, 정말 걱정되는 내용이네;
만약 우리가 ECC+ML-KEM을 고집한다면, 우리는 중요한 전환을 늦추고 있는 것일지도 몰라!'

하지만 잠시만 기다려 보세요.
지난 9월의 상황은 이랬습니다.
ML-KEM은 이미
Cloudflare HTTPS 연결의
절반에 달할 정도로 성장해 있었습니다—그리고 그것은 ECC+PQ였으며,
단독 PQ가 아니었습니다.
(구체적으로는,
"약 95%가 X25519MLKEM768이고 5%가 X25519Kyber768Draft00"였습니다; 이 둘 모두 단독 PQ가 아닌 ECC+PQ입니다.)
ML-KEM의 보안을 걱정하는 사람들에게,
단독 ML-KEM으로 전환하는 것은 어리석게 들리겠지만,
ECC+ML-KEM으로 전환하는 것은 합리적으로 들립니다.
그렇다면 보안 문제를 지적하는 것이 어떻게 전환을 늦출 수 있다는 걸까요?

2026년 7월 3일, Paul Hoffman는 자신의 찬성 투표에 대한 근거로 "신뢰할 수 있는 암호학계(cryptographic community)가 ECC+ML-KEM과 단독 ML-KEM 모두를 지지한다"라고 썼습니다. 어쩌면 당신은 이것을 보고 이렇게 생각할지도 모릅니다. '와, 암호학계가 단독 ML-KEM도 괜찮다고 생각한다면, 그것은 정말 괜찮은 것이 틀림없어!'

잠시만요. AES 및 다른 많은 잘 알려진 암호 시스템(cryptosystems)에 대해 알려진 최고의 공격법을 개발한 것으로 유명한 Orr Dunkelman은 이 "최종 의견 수렴(last call)" 기간 동안 단독 ML-KEM에 대해 이의를 제기했습니다; cryptlib의 저자인 Peter Gutmann도 이 "최종 의견 수렴" 기간 동안 단독 ML-KEM에 대해 이의를 제기했습니다; 유럽 위원회(European Commission)의 양자 내성 암호(Post-Quantum Cryptography) 팀 리더인 Fabiana Da Pieve도 이 "최종 의견 수렴" 기간 동안 단독 ML-KEM에 대해 이의를 제기했습니다; 등등 말입니다. Hoffman은—Dual EC를 더 쉽게 악용할 수 있게 만들었던 TLS 확장 기능에 대한 NSA의 추진 과정에서 자신의 과거 역할을 어떻게든 언급하는 것을 누락하고, NSA로부터 얼마나 많은 돈을 받았는지 공개하지 않으면서—이 사람들이 "신뢰할 수 없다(credible)"고 주장하는 것입니까? 와우.

2026년 7월 5일, 캐나다 사이버 보안 센터(Canadian Centre for Cyber Security, NSA의 캐나다 파트너인 CSE의 일부)와 관련하여, Kevin Milner는 "순수 ML-KEM (pure ML-KEM)을 위한 RFC가 있는지 여부는 그들의 권고 사항에 거의 확실히 영향을 미치지 않는다"라고 작성했습니다. 이는 RFC가 어떻게 "수백만 명의 시스템과 사람들에게 영향을 미치는 정책"으로 변할 수 있는지를 설명하는 반대 측의 주장에 대한 답변이었습니다. 아마 여러분은 이것을 보고, '와, 반대론자들이 RFC로 인해 발생할 피해를 과장하고 있구나!'라고 생각할지도 모릅니다!

사실, CSE의 Keegan Dasilva Barbosa가 찬성표를 던진 명시된 근거는 "사이버 센터의 TLS 가이드라인 내에 순수 ML-KEM을 포함할 계획"이라는 것이었습니다. 한 반대론자가 CSE가 "단독 ML-KEM을 권고할 수 있도록 이 문서가 출판되기를 기다리고 있다고 리스트에 작성했다"라고 언급하자, CSE의 Jonathan Hammell은 자신의 찬성표를 던지는 과정에서 "예"라고 응답했습니다. [20260706 수정: 이 단락의 복사-붙여넣기 오류를 수정함.]

저는 제 논거 및 반론 차트를 꽤 여러 번 업데이트했으며, 가장 최근에는 2026년 6월 25일에 업데이트했습니다. 찬성론자들은 모든 중요한 이의 제기를 무시하고, 이견은 "공개적인 검토와 토론 과정을 통해 해결되어야 한다"는 IETF 규칙을 무시하며 계속해서 결함이 있는 논거를 제시하고 있습니다. 찬성론자들은 단독 양자 내성 암호 (solo PQ)가 의무화된 합의 형성 (consensus-building) 과정을 견뎌낼 수 없다는 점을 이해하고 있는 듯하며, 그 대신 이를 정치적인 투표 과정으로 대체하여 노골적으로 표를 몰아주고 있습니다. 예를 들어, 우리는 다음과 같은 찬성표들을 보았습니다.

등등. [20260706 수정: Lear 추가.]

하지만 아마 여러분은 찬성론자들이 다음과 같이 주장하는 것을 들어보았을지도 모릅니다. 아니, 오히려 그 반대라고 말이죠:
반대론자들이 결함이 있는 논거를 제시하고 있으며,
그것들에 대한 모든 중요한 이의 제기를 무시하고,
표를 몰아주고 있다고 말입니다.

어쩌면 여러분은 사양 (spec)의 장점을 평가함에 있어 어느 쪽이 옳은지 확신할 수 없게 될지도 모릅니다. 이 사양에 반대하는 투표를 잘못 던질 위험을 감수하는 것이 합리적일까요? 이 사양에 찬성하는 투표를 잘못 던질 위험을 감수하는 것이 합리적일까요? 만약 확신이 서지 않는다면, 침묵을 지키는 것이 더 낫지 않을까요?

글쎄요, 그렇지 않습니다. 왜냐하면 위험 분석 (risk analysis)에는 무엇이 잘못될 수 있는지, 그리고 그것이 잘못될 가능성이 얼마나 되는지뿐만 아니라 그 결과가 무엇인지도 포함되기 때문입니다. 이 경우의 결과는 근본적으로 다릅니다. 부분적으로는 IETF의 절차에 내재된 기본적인 찬성 편향 (pro-endorsement bias) 때문이며, 또 다른 부분으로는 한 유형의 오류가 미치는 영향이 다른 유형의 영향보다 훨씬 덜 심각하기 때문입니다. 설명해 보겠습니다.

문서가 거칠 수 있는 "최종 호출 (last calls)"의 횟수를 제한하는 IETF 규칙은 없습니다.
이 특정 문서는 이미 세 번의 "최종 호출"을 거쳤습니다:
2025년 11월에 한 번,
2026년 2월에 한 번,
그리고 2026년 6월에 시작된 현재의 호출이 한 번입니다.

만약 "최종 호출" 이후에 작업 그룹 (WG) 의장들이 RFC 발행에 대한 "거친 합의 (rough consensus)"를 선언하면, 그것으로 끝입니다. 해당 WG는 해당 문서에 대한 작업을 마칩니다. 문서는 IESG라고 불리는 소규모 위원회에 의해 형식적으로 승인(rubber-stamped)된 후, "rough"라는 단어 없이, 그리고 반대 의견에 대한 어떠한 인정도 없이 "IETF 커뮤니티의 합의"를 주장하며 RFC로 출판됩니다.

IESG는 커뮤니티의 의견을 묻는 절차를 밟지만, 설령 그 의견이 압도적으로 부정적이라 할지라도 IESG가 문서를 거부하도록 강제하는 규칙은 없습니다. IESG의 대다수는 방위산업체 계약업체들로 구성되어 있으며 (NSA의 평생직원인 Deb Cooley 1명 포함), 따라서 IESG가 NSA가 주도하는 문서를 거부할 리는 없습니다. 기술적으로는 다양한 유형의 항소 (appeals)가 가능하지만, 이는 중립적인 재판소가 아니라 IESG와 이와 유사하게 편향된 위원회인 IAB에 의해 처리됩니다.

반면에,
만약 WG 의장들이 RFC 발행에 대한 "거친 합의"를 선언하지 않는다면,
규칙상 그들이 다시 시도하는 것을 막을 수 있는 것은 아무것도 없습니다.
이것이 우리가 이미 ietf-tls-mlkem에 대해 세 번째 "최종 호출"을 진행하고 있는 이유입니다.

이것이 얼마나 불공정한지 보이십니까? 이것이 초안 (draft)을 밀어붙이고 싶어 하고 IETF에 참가자들을 쏟아부을 여력이 있는 기업들에게 얼마나 편향되어 있는지 보이십니까?

IETF는 다음과 같은 규칙이 "근본적(fundamental)"이라고 말합니다:
"IETF 참가자들은 특정 네트워크, 기술, 벤더(vendor) 또는 사용자를 위한 최선의 솔루션이 아니라, 인터넷 전체를 위한 최선의 솔루션을 찾기 위해 그들의 최선의 엔지니어링 판단 (engineering judgment)을 사용한다."
또한 앞서 언급했듯이, 의견 불일치는 "공개적인 검토와 토론의 과정을 통해 해결되어야 한다"고 명시하고 있습니다.
분명히 현재 이곳에서 일어나고 있는 일은 이와 전혀 다릅니다.
사람들이 인터넷 전체를 위한 최선의 솔루션을 설계하기 위해 함께 협력하는 모습 대신, 여러분은 여전히 해결되지 않은 의견 불일치가 존재하는 투표 과정을 보고 있습니다.
이는 정치에서는 익숙한 상황이지만, IETF가 작동해야 하는 방식은 아닙니다.

이 점을 염두에 두고, 어떤 투표가 옳은지 확신할 수 없을 때 발생하는 위험에 대해 다시 한번 생각해 봅시다:

만약 당신이 해당 명세(spec)에 반대 투표를 한다면, 당신은 찬성론자들에게 협상 테이블로 나올 것을 요구하는 것입니다. 만약 더 많은 토론을 통해 당신이 해당 명세를 지지하게 된다면, 발생한 유일한 피해는 이 명세를 RFC로 발행하는 것이 지연된 것뿐입니다. 그런데 찬성론자들은 어차피 이 RFC의 사용을 권장하지 않는다고 계속 말하고 있으므로, 지연이 피해를 주고 있다고 주장할 수 없습니다! 예를 들어, 찬성론자인 Sophie Schmieg는 이 단독 ML-KEM 명세가 NSA에 의해서만 사용될 것이며, "다른 누구에게도 영향을 미치지 않을 것"이라고 주장합니다.

반대로, 어떤 투표가 옳은지 확신할 수 없어서 침묵을 지키거나, 혹은 해당 명세에 찬성 투표를 한다면,
당신은 찬성론자들이 작업 그룹(WG)을 통해 논란이 되는 문서를 합의 없이 지금 당장 밀어붙이는 것을 방관하는 셈이 됩니다.
만약 그들이 해당 명세가 안전하다는 주장 자체가 틀린 것이라면—그리고 만약 NSA가 해당 RFC를 사용하여 광범위한 배포를 유도하는 데 성공한다면—
그로 인해 발생하는 피해는
수백만 명 사용자의 보안을 파괴하는 것입니다.

지지자들과 반대자들의 진술을 클릭해 보면, 그 영향력의 거대한 차이를 계속해서 볼 수 있습니다.
반대자들은 일반적으로 PQ(양자암호) 오류가 일반 대중의 보안에 미치는 피해에 대해 이야기합니다.
한편, 전형적인 지지자의 논리는 ECC+PQ를 단독 PQ로 단순화하는 것이 '언젠가 양자 컴퓨터가 제대로 작동하기 시작하고 사람들이 양자 취약 암호학에 대한 집착을 잃게 되면' 편리할 것이라고 말합니다; 음, 좋습니다. 그렇다면 이 문서를 지연시키는 것이 정확히 어떻게 문제가 되는 걸까요?

지지자들 사이에서 가장 극단적으로 들리는 진술은 ECC+ML-KEM을 다루는 것이 '내 인생의 문자 그대로 수년'을 소비할 것이라는 주장입니다. 분명히 이 '수년'이라는 주장은 심각하게 받아들여지도록 의도된 것은 아닐 것입니다—분명히 그가 자신의 직장에서 엄청나게 무능하다고 선언하려는 것은 아닐 겁니다—하지만 더 큰 그림은 보안 전문가들이 훨씬 더 많은 사람들을 보호하기 위해 노력을 기울인다는 것입니다. 그것이 핵심입니다.

보안 실패를 피하는 공공의 이익이 얼마나 중요한지 명백하지 않습니까? 이러한 이익이 IETF에 공정하게 반영되어야 하지 않을까요?

IETF 절차에 내재된 지지 편향(pro-endorsement bias)이라는 절차적 요점으로 돌아가 보겠습니다. 이것을 확인하기는 쉽습니다. 네, 이것은 정말로 ietf-tls-mlkem의 세 번째 '마지막 요청(last call)'입니다. 이 '마지막 요청'을 보면,

한편, 22개의 이의 제기 중 15개는 ietf-tls-ecdhe-mlkem과 비교했을 때 ietf-tls-mlkem의 보안 위험에 대해 명시적으로 언급되었습니다: #4, #5, #6 (나), #7, #8, #10, #12, #13, #15, #16, #17, #18, #19, #20, 그리고 #22. 의장들은 이러한 우려 사항들이 해결되었다고 단정했습니다.

우리 중 여덟 명(그리고 훨씬 더 많은 사람들)은 이미 이번 '마지막 요청'에서 다시 이의를 제기한 기록이 있습니다. 세 번째 '마지막 요청'의 실제 기능은 불필요한 작업을 강요하는 것입니다. 이는 Cisco와 같이 IETF 회의에 100명을 보낼 여력이 있는 회사들에게는 중요하지 않을 수 있지만, 공익을 대표하는 우리들에게는 훨씬 더 중요합니다.

의장들이 전하는 메시지는 동일했습니다. 만약 '대략적인 합의(rough consensus)'가 없다면 '초안 논의를 중단하고 진척시키지 않겠다'고 말입니다. 이 주장은 마케팅 트릭일 뿐이며, IETF 규칙에 따라 의장이나 다른 문서 제안자들에게 강제할 수 있는 것이 아닙니다.

저는 이전 블로그 게시물에서 의장들이 2025년 2월에 ECC+PQ 서명(signatures)의 TLS 채택을 요청하겠다고 약속했지만, 실제로 이행하지 않았다는 점을 언급했습니다. 물론 저는 이러한 잘못된 행동에 주의를 기울이는 것이 의장들의 미래의 잘못된 행동을 저지할 것이라고 바랍니다. 하지만 IETF 규칙상 의장들이 상황이 바뀌었다거나 이것이 약속이 아니었다고 말하는 것을 막는 것은 아무것도 없습니다. 마찬가지로, 단독 ML-KEM에 대한 세 번째 '마지막 요청'이 실패한다면, IETF 규칙상 의장들이 네 번째 '마지막 요청'을 발표하는 것을 막는 것은 아무것도 없습니다. 다시 말씀드리지만, 이것은 찬반 양측에서 대칭적이지 않습니다. 만약 세 번째 '마지막 요청'이 통과된다면 그것이 최종이며 ietf-tls-mlkem에 대해 투표할 기회는 두 번 다시 없을 것입니다.