요약

  • draft-ietf-tls-tlsflags-18은 최대 2,040개의 내용이 없는 기능 표시를 하나의 TLS 확장에 담습니다. 이는I-D Exists상태의 활성 Proposed Standard 트랙 인터넷 드래프트이며, RFC나 배포 보고가 아니고, 개정판 18은 유지보수 갱신입니다.
  • 설정된 비트는 지원 또는 사용 의도를 의미할 수 있고, 제안·확인 응답·허용된 발신 표시일 수 있으며, 평문 또는 암호화된 핸드셰이크 메시지에 위치할 수 있습니다. 각 플래그 정의 사양이 확인 응답과 0-RTT 의미를 결정합니다.
  • Daniel Kade는 메시지, 방향, 역할, 정의 참조, 트랜스크립트 근거, 재개 컨텍스트, 관찰된 결과, 로컬 결정을 보존하는 플래그 해석 봉투를 제안합니다. 이는 편집 지침이지 IETF 요구사항이 아닙니다.

그 인시던트 보고서는 안심시키도록 정밀해 보였습니다. 타임스탬프, 두 개의 주소, TLS 버전,flag 8 = true가 나열되어 있었습니다. 조사자는 마지막 필드를 "기능 활성"으로 읽었습니다. 수집기는 이미 핸드셰이크 메시지, 발신자의 역할, 방향을 버린 상태였습니다. 이제 그 비트가 클라이언트의 제안인지, NewSessionTicket의 공지인지, 이전에 제안된 것에 대한 응답인지 아무도 알 수 없었습니다.

파서가 잘못된 비트를 읽었다는 증거는 없었습니다. 실패는 나중에 붙여진 명사에 있었습니다. 하나의 관찰이 상태가 되어 버린 것입니다.

이 실수는 비트가 자기완결적으로 느껴지기 때문에 일어나기 쉽습니다. 그러나 그렇지 않습니다. TLS 플래그 제안에서 같은 컨테이너는 여러 개의 독립적으로 정의된 기능을 담을 수 있습니다. 비트 위치는 하나의 사양을 식별하며, 그 사양이 존재의 의미, 운반 가능한 메시지, 응답이 필요한지, 초기 데이터에서의 동작을 알려줍니다. 이 좌표들을 제거하면 저장된 불리언은 더 이상 교환에 대한 충실한 기록이 아닙니다.

개정판 18은 드래프트를 갱신할 뿐, 완성하지 않는다

draft-ietf-tls-tlsflags-18은 2026년 9월 10일에 발행되었습니다. Datatracker는 이를 Proposed Standard 트랙을 목표로 하는 활성 TLS 워킹 그룹 인터넷 드래프트로 기술합니다. IESG 상태는I-D Exists이고, 워킹 그룹 상태는Waiting for Implementation입니다. 셰퍼드가 지정되어 있지만 담당 Area Director나 telechat 일정은 없습니다.

문서 이력이 중요한 이유는, 그렇지 않으면 이 날짜가 새로운 프로토콜 결정처럼 보일 수 있기 때문입니다. 공식17→18 비교는 개정판·날짜·만기 표지 문구만 바꾸며, 실질 규칙은 바꾸지 않습니다. 개정판 18은 이 작업을 2027년 3월까지 유지할 뿐입니다. 문서를 RFC로 만들거나, 새로운 상호운용성 근거를 기록하거나, 요청된 레지스트리 작업을 완료하지 않습니다.

TLS 워킹 그룹은 중요한 표준 문제를 담당합니다. 내용이 없는 TLS 확장은 존재 자체가 전체 표시인 경우에도 하나에 4옥텟씩 듭니다. 공통 비트 문자열은 이렇게 늘어나는 신호군을 더 저렴하게 만들 수 있습니다. 그것은 인코딩 성과입니다. 이를 보편적인 기능 상태 머신으로 표현해서는 안 됩니다.

컨테이너는 의미론이 아니라 구문을 압축한다

개정판 18 원문은 1~255옥텟의 플래그를 정의하며, 이는 0부터 2,039까지의 비트 위치를 담기에 충분합니다. 비트는 각 옥텟 안에서 최하위 비트부터 채워집니다. 발신자는 설정된 최상위 비트에 도달하는 최소 길이를 사용해야 합니다. 모두 0인 값이나 뒤에 0옥텟이 붙는 값은 유효하지 않으며, 수신자는 치명적인illegal_parameter경고로 종료해야 합니다.

이 규칙들은 구현이 비트의 위치에 합의하고 비정규 인코딩을 거부하게 합니다. 그러나 모든 비트가 무엇을 주장하는지는 말하지 않습니다. 드래프트 자체의 정의는 의도적으로 더 넓습니다. 플래그 타입 기능은 빈 확장 또는 해당 비트가 지원 또는 사용 의도를 표시하는 선택적 TLS 1.3 기능입니다. 지원과 의도는 동의어가 아닙니다.

클라이언트는 기능을 갖추었지만 이 연결에는 제안하지 않기로 할 수 있습니다. 서버는 NewSessionTicket에서 미래의 재개에 관해 허용된 단방향 표시를 보낼 수 있습니다. 피어는 기능을 실제로 작동시키는 조건에 도달하지 않고도 이해를 확인할 수 있습니다. 정책 엔진은 양쪽 엔드포인트가 호환성을 표시한 뒤에도 사용을 금지할 수 있습니다.

공유되는tls_flags확장은 이 구분들을 지울 수 없는데, 애초에 그것을 소유하도록 설계되지 않았기 때문입니다. 누락된 의미론은 각 플래그의 정의 문서가 제공해야 합니다.

제안, 확인 응답, 공지는 서로 다른 이벤트다

규칙은 발신 플래그를 ClientHello, CertificateRequest, NewSessionTicket에서만 허용합니다. ServerHello, EncryptedExtensions, Certificate, HelloRetryRequest에 나타나는 플래그는 적용 가능한 앞선 ClientHello 또는 CertificateRequest에서 제안되었었어야 합니다. 발신되지 않은 응답 위치의 플래그를 수신하면 치명적입니다.

이것은 트랜스크립트에 대한 근거이지, 시간을 초월한 객체가 아닙니다.

ClientHello에서 비트는 제안 또는 의도 표현일 수 있습니다. ServerHello나 EncryptedExtensions에서 같은 비트는 정의 사양이 확인 응답을 요구할 경우 앞선 제안에 대한 확인일 수 있습니다. NewSessionTicket에서 서버 측 플래그는 클라이언트 응답 메시지가 없으므로 절대 확인되지 않습니다. CertificateRequest와 클라이언트 Certificate에서는 방향과 역할이 뒤바뀝니다.

feature_supported라는 데이터베이스 컬럼은 이 모든 경우를 표현할 수 없습니다.offered와accepted라는 두 개의 불리언조차, 확인 응답을 요구하지 않는 플래그에는 틀릴 수 있습니다. 모델은 교환에서 시작해야 합니다. 누가 어느 비트를, 어느 핸드셰이크 메시지에서, 어느 이전 메시지 뒤에, 어느 플래그별 규칙에 따라 보냈는지입니다.

워킹 그룹은 이 경계를 명시적으로 다루었습니다.이슈 19는 컨테이너에 대해 확인 응답을 의무화해서는 안 되며 각 플래그가 자신의 동작을 지정해야 한다고 주장했습니다. 그 결과로 만들어진 규칙은 응답이 없는 플래그를 허용합니다. 이 이력은 구현 세부사항이 아니라, 정의되지 않은 확인 응답의 부재를 관찰자가 추론하지 못하도록 막습니다.

응답 규칙은 의도적으로 좁다

플래그가 확인 응답을 요구하는 경우, 응답은tls_flags안의 같은 플래그여야 합니다. 응답에 내용을 갖는 일반 확장이 필요하다면 이 컨테이너를 사용해서는 안 됩니다. 이 제한은 1비트 확인이 구조화된 협상을 사칭하지 못하게 합니다.

이는 성공한 교환이 증명할 수 있는 범위도 제한합니다. 제안과 확인의 일치는 피어들이 정의된 신호 규칙을 따랐음을 보여줍니다. 기능이 나중에 실행되었는지, 의도된 애플리케이션 결과를 산출했는지, 정책 평가 후에도 활성 상태로 남았는지, 사양이 다루지 않는 용도에 대해 안전했는지는 증명하지 않습니다.

RFC 8446은 이미 유용한 예를 제공합니다. 빈post_handshake_auth확장은 클라이언트가 핸드셰이크 후 인증을 수행할 의사가 있음을 표시합니다. 서버는 나중에 CertificateRequest를 보낼 수 있습니다. 의사의 표시는 이후 요청이 발생했는지, 클라이언트가 인증서를 제출했는지, 애플리케이션이 결과 신원을 승인했는지에 대한 근거가 아닙니다. 내용이 없는 표시는 정확하면서도 여전히 더 긴 사슬의 첫 번째 이벤트일 뿐입니다.

초기 데이터는 시간을 초월한 불리언을 특히 위험하게 만든다

TLS 1.3 재개는 새 핸드셰이크가 완료되기 전에 0-RTT 애플리케이션 데이터를 운반할 수 있습니다. 플래그 컨테이너는 그 교환의 핸드셰이크 메시지에 나타날 수 있지만, 개정판 18은 모든 미래 플래그에 공통된 초기 데이터 의미를 부여하지 않습니다. 각 플래그 사양이 0-RTT와의 상호작용을 정의해야 합니다.

이 경계는 워킹 그룹의이슈 16에 기록되어 있습니다. 컨테이너는 인코딩 프레임워크이며, 개별 트리비얼 확장이 초기 데이터 의미론의 책임을 유지합니다. 그것이 맞는 역할 분담입니다. 어떤 기능은 재개를 넘어 기억하는 것이 안전할 수 있고, 다른 하나는 새로운 확인이 필요할 수 있으며, 셋째는 미래의 티켓에만 영향을 줄 수 있습니다.

flag=true는 유지하면서도 연결이 완전 핸드셰이크였는지 재개였는지, 초기 데이터가 시도되거나 수락되었는지, 어느 플래그 사양이 교환을 지배했는지를 버리는 수집기는 이후 상태를 이전 바이트에 적용할 수 있습니다. 그것은 관측성 결함 이상입니다. 어떤 동작이 발생했을 때 어떤 정책이 적용되었는지에 대한 보안 또는 컴플라이언스 결론을 오염시킬 수 있습니다.

메시지 배치는 비트를 관찰할 수 있는 주체를 바꾼다

드래프트는 ServerHello와 HelloRetryRequest의 확인 응답이 수동 관찰자에게 노출된다고 경고합니다. 대부분의 확인 응답은 노출시킬 구체적 이유가 없다면 암호화된 메시지에 있어야 합니다.

결과적으로 같은 플래그에 대한 두 개의 기록은 서로 다른 가시성 권한을 가질 수 있습니다. 경로 모니터는 ServerHello의 비트를 볼 수 있습니다. 읽을 수 없었다는 이유만으로 EncryptedExtensions에 동등한 비트가 없었다고 가정할 수는 없습니다. 엔드포인트 로그는 암호화된 트랜스크립트를 볼 수 있지만 서로 다른 신뢰 및 보존 경계를 지닙니다. 미들박스가 생성한 요약은 평문 핸드셰이크만 알 수 있습니다.

따라서 "관찰되지 않음"은 관찰 지점을 명명해야 합니다. 수동 캡처, 클라이언트 엔드포인트, 서버 엔드포인트, 종단 프록시는 하나의 시야를 공유하지 않습니다. 플래그의 메시지 위치는 프로토콜 좌표이면서 동시에 공개 결정입니다.

레지스트리 상태는 지도이지 실행 추적이 아니다

개정판 18은 Value, Flag Name, Message, Recommended, Reference 필드를 갖는TLS Flags레지스트리를 요청합니다. 값 0~15는 Standards Action이 필요하고, 값 16~2039는RFC 8126에 따라 Specification Required를 사용합니다. 최초 제안 플래그는 값 8, NewSessionTicket의resumption_across_names이며 Recommended는N입니다.

조사 기준 시점에 실제IANA TLS ExtensionType 레지스트리는 별도로tls_flags컨테이너 자체를 확장 값 62로, CH, SH, HRR, EE, CR, CT, NST에서 허용되며 RecommendedN과 드래프트 개정판 14 참조와 함께 등재하고 있었습니다. 그것은 현재의 레지스트리 근거입니다. 드래프트가 RFC가 되었거나, 요청된 플래그 레지스트리가 완성되었거나, 구현이 특정 플래그를 지원한다는 근거는 아닙니다.

RFC 8447은 이 범주 오류에 대해 이례적으로 명확합니다. RecommendedN이 결함을 의미하지는 않습니다. 항목은 적용 범위가 제한적이거나, IETF 합의가 없거나, 특정 용도에 사용될 수 있습니다. 지정 전문가의 승인은 인정으로 읽혀서는 안 됩니다. 현재의8447bis 작업은 레지스트리 언어를 다듬을 수 있고, 현재의8446bis 작업은 프로토콜 사양을 개정합니다. 둘 다 진행 중인 작업입니다.

레지스트리는 파서에게 사용할 좌표와 참조를 알려줍니다. 무엇이 전송되었는지는 트랜스크립트만 보여줍니다. 그것이 무엇을 의미했는지는 정의 사양만 알려줍니다. 그 후 무엇이 일어났는지는 로컬 근거만 보여줍니다.

잘못된 구문은 경계가 정해진 실패를 증명할 뿐이다

치명적 규칙들은 모호한 인코딩을 막기 때문에 유용합니다. 수신자는 모두 0인 값, 뒤따르는 0옥텟, 길이 0 인코딩, 허용되지 않는 응답 위치에 보내진 플래그를 거부할 수 있습니다. 이 핸드셰이크에 대해 깨끗한 프로토콜 결과를 제공합니다.

그러나 조직적 원인을 식별하지는 못합니다. 발신자는 오래된 라이브러리, 낡은 레지스트리 스냅샷, 결함이 있는 직렬화기, 잘못된 메시지에 실험적 플래그를 켠 정책, 또는 공격자가 제어한 입력을 사용했을 수 있습니다. 치명적 경고는 어느 것인지 말하지 않습니다. 성공한 핸드셰이크 역시 기능에 대한 모든 애플리케이션 수준 가정이 충족되었음을 증명하지 않습니다.

인시던트 기록은 진단을 추가하기 전에 원시의 경계가 정해진 이유—메시지, 방향, 바이트, 파서 버전, 경고—를 보존해야 합니다. "기능 실패"는 이미 추론입니다. "ServerHello에서 뒤따르는 0옥텟을 갖는tls_flags를 수신하고illegal_parameter를 발행함"은 관찰입니다.

플래그 해석 봉투를 만들어라

해결책은 또 하나의 보편적 기능 불리언이 아닙니다. 각 관찰을 감싸는 작은 봉투입니다.

트래픽 비밀을 저장하지 않고 연결 또는 트랜스크립트 근거 참조를 기록합니다. TLS 버전, 완전 핸드셰이크 여부 또는 재개 여부, 0-RTT의 제안·수락·거부 여부, 엔드포인트 역할과 방향, 정확한 핸드셰이크 메시지, 컨테이너 확장 값, 원시 비트 문자열 해시와 정규화된 길이, 비트 위치, 레지스트리 스냅샷, 정의 사양과 개정판, 이 이벤트가 제안인지 확인인지 허용된 발신 표시인지를 기록합니다.

그런 다음 이 플래그에 확인이 필요한지, 어떤 이전 제안에 응답하는지, 일치하는 피어 근거, 치명적 검증 결과가 있었는지를 기록합니다. 평문 가시성을 엔드포인트 전용 가시성과 분리합니다. 비트를 해석한 파서 빌드와 정책 버전을 명명합니다.

마지막으로 관찰된 후속 결과를 보존합니다. 이해됨, 선택됨, 실행됨, 실패, 대체됨 또는 알 수 없음. 이에 의존할 수 있는 로컬 결정, 결정 소유자, 보존, 허용된 소비자, 불확실성, 만기, 종결 근거를 첨부합니다. 보안 통제자는 실행 근거를 요구할 수 있고, 용량 연구는 집계 제안 수만 필요할 수 있습니다. 같은 비트가 양쪽에 똑같이 충분하지는 않습니다.

이플래그 해석 봉투는 Daniel Kade의 거버넌스 제안입니다. TLS를 바꾸거나, 번호를 할당하거나, IETF 요구사항을 추가하지 않습니다. 각 기관이 자신의 근거가 제공하는 것 이상을 주장하지 않도록 합니다.

공개 주장은 한 단계씩 올려라

"서버 NewSessionTicket에서 비트 8이 관찰됨"은 트랜스크립트 주장입니다. "그 티켓이 사양 개정판 R에 따라 이름 간 재개를 공지함"은 해석 주장입니다. "클라이언트가 나중에 그 재개를 시도함"은 실행 주장입니다. "서버가 정책 P에 따라 이를 수락함"은 결정 주장입니다. "애플리케이션이 결과 신원을 승인된 것으로 취급함"은 그보다 더 이후의 주장입니다.

어느 주장도 다음 주장의 권위를 상속받아서는 안 됩니다.

압축은 반복되는 구문을 줄이기 때문에 가치가 있습니다. 거버넌스는 그 압축된 구문이 과장된 결론이 되지 않도록 하기 때문에 가치가 있습니다. TLS 플래그는 메시지 속 비트의 완벽한 근거일 수 있습니다. 그러나 그것만으로는 기능의 상태에 대한 기록이 아닙니다.

출처