요약

  • 10월 27일 나온 개인 Internet-Draft 01판은 TLS 1.3 암호 스위트와 별도로 SHAKE256 또는 TurboSHAKE256 키 스케줄을 고르는 방안을 제안한다. 7월 00판에서 제외했던 DTLS와 Exported Authenticator를 새로 다룬다.
  • 인증기가 TLS 라이브러리 밖에 있다면 선택된 KDF의 식별자, 또는 새 KDF를 선택하지 않았다는 사실, 그리고 TLS·DTLS 구분을 전달해야 한다. 기존 exporter 호출만으로는 이 정보를 얻을 수 없다.

운영 화면에는 TLS_AES_128_GCM_SHA256이 보인다. 누군가 연결을 SHA-256 항목에 넣는다. 그러나 XOF 키 스케줄 초안 01판의 schedule_profile 확장이 협상되면, 키를 만드는 함수는 암호 스위트와 따로 고른 SHAKE256이나 TurboSHAKE256일 수 있다. 스위트는 여전히 AEAD를 정하고 이름에도 해시가 남는다. 새 KDF를 쓸 때 그 해시는 키 스케줄을 지휘하지 않는다. 표찰은 익숙하지만, 기계 안의 기어가 달라진다.

7월의 00판은 DTLS 1.3과 Exported Authenticator를 명시적으로 범위 밖에 뒀다. 이번 개정안은 둘을 포함하고 RFC 네 건의 갱신을 제안한다. 그중 RFC 9261은 핸드셰이크가 끝난 뒤 어느 한쪽이 다시 자신의 신원을 증명하는 절차를 정의한다. 기존 인증기의 해시 계산은 암호 스위트의 해시에 기대었다. 개정안 14.2절은 XOF가 선택된 연결에서 KDF의 64옥텟 TranscriptHash를 쓰고 exporter 값과 Finished의 MAC도 선택된 KDF에 맞춘다.

확장을 협상하지 않은 연결에는 기존 TLS 1.3의 HKDF와 기존 인증기 규칙이 적용된다. 따라서 인증기를 따로 구현한 애플리케이션은 상대와 실제로 무엇을 골랐는지 알아야 한다. 초안은 선택된 KDF 식별자나 새 KDF가 없다는 표시를 반드시 받도록 한다. TLS인지 DTLS인지도 전달해야 한다. DTLS는 내부 키 스케줄 레이블이 다르기 때문이다.

여기서 라이브러리와 애플리케이션의 책임이 갈린다. TLS-Exporter(label, context, length)는 파생된 값을 반환해도 KDF 선택과 프로토콜 구분을 알려주지 않는다. 라이브러리만 새 핸드셰이크를 구현하면 옆의 프로그램은 옛 규칙으로 핸드셰이크 후 증명값을 만들 수 있다. 초안은 그렇게 만든 인증기가 호환되지 않을 수 있다고 직접 쓴다. 성공한 연결 검사와 실패한 신원 증명이 한 제품 안에서 동시에 존재할 수 있는 구조다.

개정안은 사전 공유키와 세션 재개 티켓에도 KDF 선택을 묶고, PSK에는 RFC 9258의 식별자를 사용한다. 인증서 서명은 별도로 협상하므로 키 스케줄을 XOF로 바꿔도 서명이나 인증서 체인에는 SHA-2가 남을 수 있다. Datatracker의 상태는 아직 개인 초안 I-D Exists다. 확인한 자료에는 새 경계에서 서로 다른 라이브러리가 인증기를 통과시킨 독립 시험 결과가 없다. TLS와 DTLS 양쪽에서 XOF를 선택한 뒤 Finished 검증까지 성공한 결과가 그 빈칸을 채운다.