1.1. 규칙 및 용어

이 문서의 핵심 단어 "반드시", "해서는 안 됨", "필수", "해야 함", "해서는 안 됨", "권고됨", "권고되지 않음", "권고", "권고하지 않음", "할 수 있음" 및 "선택 사항"은 여기에서처럼 모두 대문자로 표시된 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석해야 한다.¶

다음 용어를 사용한다.¶

클라이언트:

TLS 연결을 시작하는 엔드포인트.¶

연결:

두 엔드포인트 간의 전송 계층 연결.¶

엔드포인트:

연결의 클라이언트 또는 서버.¶

핸드셰이크:

TLS 내에서 이후 상호작용의 매개변수를 설정하는 클라이언트와 서버 간의 초기 협상.¶

피어:

엔드포인트. 특정 엔드포인트를 논의할 때 "피어"는 논의의 주된 대상이 아닌 엔드포인트를 가리킨다.¶

수신자:

레코드를 수신하는 엔드포인트.¶

송신자:

레코드를 전송하는 엔드포인트.¶

서버:

TLS 연결을 시작하지 않은 엔드포인트.¶

1.2. RFC 8446과의 관계

TLS 1.3은 원래 [RFC8446]에 명세되었다. 이 문서는 동일한 버전 번호를 유지하고 하위 호환되는 TLS 1.3의 소규모 갱신이다. 일부 요구사항을 강화하고, 명확하지 않은 것으로 확인된 영역의 갱신된 텍스트와 기타 편집상 개선 사항을 포함한다. 또한 비밀값에 적용되던 "master"라는 용어를 "main"이나, 용어가 필요하지 않은 경우에는 더 짧은 이름으로 대체한다. 이 문서는 다음과 같은 구체적인 기술 변경을 수행한다.¶

• 연결 간 KeyShare 값의 재사용을 금지한다.¶

• [RFC8996]에 따라 현재 사용 중단된 TLS 1.0 및 1.1의 협상을 금지한다.¶

• PreSharedKeys 및 HelloRetryRequest와 함께 사용되는 해시에 관한 모호성을 제거한다.¶

• 재개를 지원하지 않는 클라이언트가 NewSessionTicket을 무시하도록 요구한다.¶

• 키 사용 제한을 초과하기 전에 키 갱신을 시작해야 한다는 요구사항을 반드시로 강화하고 키 사용 제한의 범위를 명확히 한다.¶

• 허용되는 KeyUpdate 메시지 수를 제한한다.¶

• "close_notify" 수준을 "warning"으로 정의하는 텍스트를 복원한다.¶

• "user_canceled" 관련 동작을 명확히 하여, "close_notify"를 전송해야 하고 "user_canceled"를 무시하는 것이 좋다고 요구한다.¶

• 일반 "general_error" 경고를 추가한다.¶

• CertificateRequest.extensions의 하한을 0바이트로 수정한다. 확장을 전송하지 않아 길이가 0이 될 수 있으므로 이는 구문상의 오류였다.¶

• ClientHello.extensions의 하한을 수정한다. 이는 계산 오류였다.¶

• NewSessionTicket.extensions의 상한을 수정한다. 이는 계산 오류였다.¶

• 이전에 (EC)DHE로만 한정되었던 비대칭 키 교환에 더 일반적인 표현을 사용하여 KEM 기반 키 교환의 사용을 반영한다.¶

• 트랜스크립트 해시와 향후 명세 간의 상호작용을 명확히 한다.¶

• [RFC9963]에 맞춰 RSA PSS를 요구하는 텍스트를 제거한다.¶

또한 특히 개인정보 보호와 관련된 보안 고려사항이 일부 개선되었다.¶

1.3. TLS 1.2와의 주요 차이점

다음은 TLS 1.2와 TLS 1.3 간의 주요 기능적 차이점 목록이다. 모든 차이점을 열거하려는 것은 아니며, 그 밖에도 사소한 차이점이 많이 있다.¶

• 지원되는 대칭 암호화 알고리즘 목록에서 레거시로 간주되는 모든 알고리즘이 제거되었다. 남아 있는 알고리즘은 모두 연관 데이터가 있는 인증된 암호화(AEAD) 알고리즘이다. 암호 스위트 개념은 인증 및 키 교환 메커니즘을 레코드 보호 알고리즘 (비밀 키 길이 포함), 키 유도 함수와 핸드셰이크 메시지 인증 코드(MAC)에 모두 사용할 해시로부터 분리하도록 변경되었다.¶

• 제로 라운드 트립 시간(0-RTT) 모드가 추가되어, 특정 보안 속성을 희생하는 대신 일부 애플리케이션 데이터의 연결 설정 시 라운드 트립을 하나 줄인다.¶

• 정적 RSA 및 디피-헬먼 암호 스위트가 제거되었다. 이제 모든 공개 키 기반 키 교환 메커니즘은 순방향 비밀성을 제공한다.¶

• 이제 ServerHello 이후의 모든 핸드셰이크 메시지는 암호화된다. 새로 도입된 EncryptedExtensions 메시지를 통해 이전에 ServerHello에서 평문으로 전송되던 여러 확장도 기밀성 보호를 받을 수 있다.¶

• 키 유도 함수가 재설계되었다. 새로운 설계는 향상된 키 분리 속성으로 인해 암호학자가 더 쉽게 분석할 수 있게 한다. HMAC 기반 추출 및 확장 키 유도 함수(HKDF)가 기반 프리미티브로 사용된다.¶

• 핸드셰이크 상태 머신은 일관성을 높이고 ChangeCipherSpec과 같은 불필요한 메시지를 제거하도록 크게 재구성되었다(미들박스 호환성에 필요한 경우 제외).¶

• 이제 타원 곡선 알고리즘은 기본 명세에 포함되며, EdDSA와 같은 새로운 서명 알고리즘도 포함된다. TLS 1.3은 각 곡선에 단일 포인트 형식을 사용하는 대신 포인트 형식 협상을 제거했다.¶

• RSA 패딩을 RSA 확률적 서명 방식(RSASSA-PSS)을 사용하도록 변경하고 압축, 디지털 서명 알고리즘(DSA) 및 사용자 정의 임시 디피-헬먼(DHE) 그룹을 제거하는 등의 암호화 개선이 이루어졌다.¶

• TLS 1.2 버전 협상 메커니즘은 확장의 버전 목록을 사용하도록 대체되며 사용 중단되었다. 이는 버전 협상을 잘못 구현한 기존 서버와의 호환성을 높인다.¶

• 서버 측 상태를 사용하는 세션 재개와 사용하지 않는 세션 재개, 그리고 이전 TLS 버전의 PSK 기반 암호 스위트는 하나의 새로운 PSK 교환으로 대체되었다.¶

• 참조는 적절한 경우 갱신된 RFC 버전을 가리키도록 갱신되었다(예: RFC 3280 대신 RFC 5280).¶

1.4. TLS 1.2에 영향을 미치는 갱신 사항

이 문서는 TLS 1.3을 지원하지 않는 구현을 포함하여 TLS 1.2 구현에 선택적으로 영향을 미치는 몇 가지 변경 사항을 정의한다.¶

• 버전 다운그레이드 보호 메커니즘은 섹션 4.2.3에 설명되어 있다.¶

• RSASSA-PSS 서명 방식은 섹션 4.3.3에 정의되어 있다.¶

• "supported_versions" ClientHello 확장은 ClientHello의 legacy_version 필드보다 우선하여 사용할 TLS 버전을 협상하는 데 사용할 수 있다.¶

• "signature_algorithms_cert" 확장을 통해 클라이언트는 X.509 인증서에서 검증할 수 있는 서명 알고리즘을 나타낼 수 있다.¶

• 비밀값에 적용되던 "master"라는 용어가 제거되었으며, "extended_master_secret" 확장 [RFC7627]은 "extended_main_secret"으로 이름이 변경되었다.¶

또한 이 문서는 이전 TLS 버전에 대한 일부 준수 요구사항을 명확히 한다. 섹션 9.3을 참조한다.¶

2.1. 잘못된 DHE 공유값

클라이언트가 충분한 "key_share" 확장을 제공하지 않은 경우 (예: 서버가 허용하지 않거나 지원하지 않는 DHE 또는 ECDHE 그룹만 포함한 경우), 서버는 HelloRetryRequest를 사용해 불일치를 수정하며, 클라이언트는 그림 2와 같이 적절한 "key_share" 확장을 사용해 핸드셰이크를 다시 시작해야 한다. 공통 암호화 매개변수를 협상할 수 없는 경우, 서버는 적절한 경고와 함께 핸드셰이크를 반드시 중단해야 한다.¶

      클라이언트                                           서버

      ClientHello
      + key_share             -------->
                                                HelloRetryRequest
                              <--------               + key_share
      ClientHello
      + key_share             -------->
                                                      ServerHello
                                                      + key_share
                                            {EncryptedExtensions}
                                            {CertificateRequest*}
                                                   {Certificate*}
                                             {CertificateVerify*}
                                                       {Finished}
                              <--------       [애플리케이션 데이터*]
      {Certificate*}
      {CertificateVerify*}
      {Finished}              -------->
      [애플리케이션 데이터]   <------->        [애플리케이션 데이터]

참고: 핸드셰이크 트랜스크립트에는 초기 ClientHello/HelloRetryRequest 교환이 포함되며, 새로운 ClientHello로 재설정되지 않는다.¶

TLS는 다음 섹션에 설명된 것처럼 기본 핸드셰이크의 여러 최적화된 변형도 허용한다.¶

2.2. 재개 및 사전 공유 키(PSK)

TLS PSK는 외부에서 설정할 수 있지만, 이전 연결에서 설정한 후 새 연결을 설정하는 데 사용할 수도 있다(PSK를 통한 "세션 재개" 또는 "재개"). 핸드셰이크가 완료되면 서버는 초기 핸드셰이크에서 유도된 고유 키에 해당하는 PSK 식별자를 클라이언트에 전송할 수 있다(섹션 4.7.1 참조). 그러면 클라이언트는 향후 핸드셰이크에서 해당 PSK 식별자를 사용해 연관된 PSK의 사용을 협상할 수 있다. 서버가 PSK를 수락하면 새 연결의 보안 콘텍스트는 원래 연결에 암호학적으로 연결되며, 전체 핸드셰이크 대신 초기 핸드셰이크에서 유도된 키를 사용해 암호화 상태를 부트스트랩한다. TLS 1.2 이하에서는 이 기능이 "세션 ID"와 "세션 티켓" [RFC5077]으로 제공되었다. 두 메커니즘 모두 TLS 1.3에서 폐기되었다.¶

PSK는 비대칭 키 교환과 함께 사용하여 공유 키와 결합된 순방향 비밀성을 제공할 수 있으며, 단독으로도 사용할 수 있지만 이 경우 애플리케이션 데이터의 순방향 비밀성을 잃게 된다.¶

그림 3은 첫 번째 핸드셰이크에서 PSK를 설정하고 두 번째 핸드셰이크에서 이를 사용하는 핸드셰이크 쌍을 보여준다.¶

       클라이언트                                           서버

초기 핸드셰이크:
       ClientHello
       + key_share               -------->
                                                       ServerHello
                                                       + key_share
                                             {EncryptedExtensions}
                                             {CertificateRequest*}
                                                    {Certificate*}
                                              {CertificateVerify*}
                                                        {Finished}
                                 <--------     [애플리케이션 데이터*]
       {Certificate*}
       {CertificateVerify*}
       {Finished}                -------->
                                 <--------      [NewSessionTicket]
       [애플리케이션 데이터]     <------->      [애플리케이션 데이터]


후속 핸드셰이크:
       ClientHello
       + key_share*
       + psk_key_exchange_modes
       + pre_shared_key          -------->
                                                       ServerHello
                                                  + pre_shared_key
                                                      + key_share*
                                             {EncryptedExtensions}
                                                        {Finished}
                                 <--------     [애플리케이션 데이터*]
       {Finished}                -------->
       [애플리케이션 데이터]     <------->      [애플리케이션 데이터]

서버는 PSK를 통해 인증하므로 Certificate 또는 CertificateVerify 메시지를 전송하지 않는다. 클라이언트가 PSK를 통해 재개를 제안하는 경우 필요하다면 서버가 재개를 거부하고 전체 핸드셰이크로 대체할 수 있도록 "key_share" 확장도 서버에 제공하는 것이 권고된다. 서버는 PSK 키 설정의 사용을 협상하기 위해 "pre_shared_key" 확장으로 응답하며, 여기에서처럼 비대칭 키 설정을 수행하기 위해 "key_share" 확장으로 응답하여 순방향 비밀성을 제공할 수도 있다.¶

PSK를 외부에서 프로비저닝하는 경우 PSK 식별자와 PSK에 사용할 KDF 해시 알고리즘도 반드시 프로비저닝해야 한다.¶

참고: 외부에서 프로비저닝된 사전 공유 비밀값을 사용하는 경우, [RFC4086]에서 설명한 것처럼 키 생성 중 충분한 엔트로피를 사용하는 것이 매우 중요하다. 암호나 기타 낮은 엔트로피 소스에서 공유 비밀값을 유도하는 것은 안전하지 않다. 낮은 엔트로피의 비밀값 또는 암호는 PSK 바인더를 기반으로 한 사전 공격에 취약하다. 명세된 PSK 인증은 비대칭 키 설정과 함께 사용하더라도 강력한 암호 기반 인증 키 교환이 아니다. 특히 핸드셰이크를 관찰할 수 있는 공격자가 암호/사전 공유 키에 대해 무차별 대입 공격을 수행하는 것을 방지하지 못한다.¶

2.3. 0-RTT 데이터

클라이언트와 서버가 외부에서 얻었거나 이전 핸드셰이크를 통해 얻은 PSK를 공유하는 경우, TLS 1.3을 사용하면 클라이언트가 첫 번째 플라이트에서 데이터("초기 데이터")를 전송할 수 있다. 클라이언트는 PSK를 사용해 서버를 인증하고 초기 데이터를 암호화한다.¶

그림 4와 같이 0-RTT 데이터는 첫 번째 플라이트의 1-RTT 핸드셰이크에 추가된다. 나머지 핸드셰이크는 PSK 재개를 사용하는 1-RTT 핸드셰이크와 동일한 메시지를 사용한다.¶

      클라이언트                                           서버

      ClientHello
      + early_data
      + key_share*
      + psk_key_exchange_modes
      + pre_shared_key
      (애플리케이션 데이터*) -------->
                                                      ServerHello
                                                 + pre_shared_key
                                                     + key_share*
                                            {EncryptedExtensions}
                                                    + early_data*
                                                       {Finished}
                              <--------       [애플리케이션 데이터*]
      (EndOfEarlyData*)
      {Finished}              -------->
      [애플리케이션 데이터]   <------->        [애플리케이션 데이터]

            +  앞서 표시된 메시지에서 전송되는 주목할 만한
               확장을 나타낸다.

            *  항상 전송되는 것은 아닌 선택적 또는 상황 의존적
               메시지/확장을 나타낸다.

            () client_early_traffic_secret에서 유도된
               키를 사용해 보호되는 메시지를 나타낸다.

            {} [sender]_handshake_traffic_secret에서 유도된
               키를 사용해 보호되는 메시지를 나타낸다.

            [] [sender]_application_traffic_secret_N에서 유도된
               키를 사용해 보호되는 메시지를 나타낸다.

중요 참고: 0-RTT 데이터의 보안 속성은 다른 종류의 TLS 데이터보다 약하다. 구체적으로 다음과 같다.¶

1. 프로토콜은 이 데이터에 대해 어떠한 순방향 비밀성도 보장하지 않는다. 적용되는 순방향 비밀성 보장이 있다면 서버의 동작에 따라 결정된다 (섹션 8.1 참조). 이 동작은 프로토콜의 일부로 클라이언트에 전달되지 않는다. 따라서 서버 동작에 대한 대역 외 정보가 없다면 클라이언트는 이 데이터에 순방향 비밀성이 없다고 간주해야 한다.¶

2. 연결 간 재전송 불가 보장은 없다. 일반 TLS 1.3 1-RTT 데이터의 재전송 방지는 서버의 Random 값으로 제공되지만, 0-RTT 데이터는 ServerHello에 의존하지 않으므로 보장이 더 약하다. 이는 데이터가 TLS 클라이언트 인증이나 애플리케이션 프로토콜 내부에서 인증되는 경우 특히 중요하다. 동일한 경고가 early_exporter_secret의 모든 사용에도 적용된다.¶

0-RTT 데이터는 연결 내에서 복제될 수 없으며 (즉, 서버는 동일한 연결에서 같은 데이터를 두 번 처리하지 않음), 공격자는 0-RTT 데이터가 1-RTT 데이터인 것처럼 보이게 할 수 없다 (서로 다른 키로 보호되기 때문). 부록 F.5에는 잠재적인 공격에 대한 설명이 있으며, 섹션 8에서는 서버가 재전송의 영향을 제한하는 데 사용할 수 있는 메커니즘을 설명한다.¶

3.1. 기본 블록 크기

모든 데이터 항목의 표현은 명시적으로 지정된다. 기본 데이터 블록 크기는 1바이트(즉, 8비트)이다. 여러 바이트로 구성된 데이터 항목은 왼쪽에서 오른쪽으로, 위에서 아래로 바이트를 이어 붙인 것이다. 바이트 스트림에서 여러 바이트 항목(다음 예에서는 숫자)은 C 표기법을 사용해 다음과 같이 구성된다.¶

   value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
           ... | byte[n-1];

여러 바이트 값에 대한 이 바이트 순서는 일반적인 네트워크 바이트 순서, 즉 빅 엔디언 형식이다.¶

3.2. 기타 사항

주석은 "/*"로 시작하고 "*/"로 끝난다.¶

해석되지 않은 데이터를 포함하는 단일 바이트 엔터티의 형식은 opaque이다.¶

기존 형식 T에 대한 형식 별칭 T'는 다음과 같이 정의한다.¶

   T T';

3.3. 숫자

기본 숫자 데이터 형식은 부호 없는 바이트(uint8)이다. 더 큰 모든 숫자 데이터 형식은 섹션 3.1에 설명된 대로 이어 붙인 고정 길이 바이트 시퀀스로 구성되며, 역시 부호가 없다. 다음 숫자 형식은 미리 정의되어 있다.¶

   uint8 uint16[2];
   uint8 uint24[3];
   uint8 uint32[4];
   uint8 uint64[8];

여기와 명세의 다른 모든 곳에서 모든 값은 네트워크 바이트 (빅 엔디언) 순서로 전송된다. 16진수 바이트 01 02 03 04로 표현된 uint32는 십진수 값 16909060과 같다.¶

3.4. 벡터

벡터(1차원 배열)는 동종 데이터 요소의 스트림이다. 표현을 위해 이 명세에서는 벡터를 목록이라고 부른다. 벡터의 크기는 문서 작성 시 지정하거나 런타임까지 지정하지 않을 수 있다. 어느 경우든 길이는 벡터의 요소 수가 아니라 바이트 수를 선언한다. 형식 T의 고정 길이 벡터인 새 형식 T'를 지정하는 구문은 다음과 같다.¶

   T T'[n];

여기에서 T'는 데이터 스트림에서 n바이트를 차지하며, n은 T 크기의 배수이다. 벡터 길이는 인코딩된 스트림에 포함되지 않는다.¶

다음 예에서 Datum은 프로토콜이 해석하지 않는 연속된 3바이트로 정의되며, Data는 연속된 세 개의 Datum으로서 총 9바이트를 사용한다.¶

   opaque Datum[3];      /* 해석되지 않는 세 바이트 */
   Datum Data[9];        /* 연속된 세 개의 3바이트 벡터 */

가변 길이 벡터는 <floor..ceiling> 표기법을 사용하여 허용되는 길이의 하위 범위를 양 끝값을 포함해 지정하는 방식으로 정의한다. 이를 인코딩할 때 실제 길이가 바이트 스트림에서 벡터 내용보다 앞에 온다. 길이는 벡터에 지정된 최대(ceiling) 길이를 담는 데 필요한 만큼의 바이트를 사용하는 숫자 형식이다. 실제 길이 필드가 0인 가변 길이 벡터를 빈 벡터라고 한다.¶

   T T'<floor..ceiling>;

다음 예에서 "mandatory"는 opaque 형식의 데이터를 300바이트 이상 400바이트 이하 포함해야 하는 벡터이다. 빈 벡터일 수 없다. 실제 길이 필드는 값 400을 표현하기에 충분한 uint16인 2바이트를 사용한다(섹션 3.3 참조). 마찬가지로 "longer"는 최대 800바이트의 데이터, 즉 400개의 uint16 요소를 나타낼 수 있으며 비어 있을 수도 있다. 인코딩에는 벡터 앞에 추가되는 2바이트 실제 길이 필드가 포함된다. 인코딩된 벡터의 길이는 단일 요소 길이의 정확한 배수여야 한다 (예: 17바이트 길이의 uint16 벡터는 허용되지 않음).¶

   opaque mandatory<300..400>;
         /* 길이 필드는 2바이트이며 비어 있을 수 없음 */
   uint16 longer<0..800>;
         /* 0개에서 400개의 16비트 부호 없는 정수 */

3.5. 열거형

"enum" 또는 "enumerated"라고 하는 추가적인 희소 데이터 형식을 사용할 수 있다. 각 정의는 서로 다른 형식이다. 동일한 형식의 열거형만 할당하거나 비교할 수 있다. 다음 예에서와 같이 열거형의 모든 요소에는 값을 할당해야 한다. 열거형 요소에는 순서가 없으므로 어떤 순서로든 고유한 값을 할당할 수 있다.¶

   enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;

향후 프로토콜 확장 또는 추가 사항에서 새로운 값을 정의할 수 있다. 필드 정의에 달리 명시되지 않는 한 구현은 알 수 없는 값을 파싱하고 무시할 수 있어야 한다.¶

열거형은 정의된 최대 서수 값이 차지하는 만큼의 바이트 스트림 공간을 사용한다. 다음 정의에서는 Color 형식의 필드를 전달하는 데 1바이트가 사용된다.¶

   enum { red(3), blue(5), white(7) } Color;

불필요한 요소를 정의하지 않고 너비 정의를 강제하기 위해 연관된 태그 없이 값을 선택적으로 지정할 수 있다.¶

다음 예에서 Taste는 데이터 스트림에서 2바이트를 사용하지만 현재 프로토콜 버전에서는 값 1, 2 또는 4만 가질 수 있다.¶

   enum { sweet(1), sour(2), bitter(4), (32000) } Taste;

열거형 요소의 이름은 정의된 형식 내에서 범위가 지정된다. 첫 번째 예에서 열거형의 두 번째 요소를 완전히 한정하여 참조하면 Color.blue가 된다. 할당 대상이 잘 지정된 경우에는 이러한 한정이 필요하지 않다.¶

   Color color = Color.blue;     /* 과도하게 지정되었지만 적법함 */
   Color color = blue;           /* 올바름, 형식이 암시됨 */

열거형에 할당된 이름은 고유할 필요가 없다. 숫자 값은 동일한 이름이 적용되는 범위를 나타낼 수 있다. 값에는 해당 범위의 최솟값과 최댓값이 포함되며, 두 개의 마침표 문자로 구분한다. 이는 주로 공간의 영역을 예약하는 데 유용하다.¶

   enum { sad(0), meh(1..254), happy(255) } Mood;

3.6. 구성형

편의를 위해 기본형으로부터 구조체 형식을 구성할 수 있다. 각 명세는 새롭고 고유한 형식을 선언한다. 정의에 사용되는 구문은 C와 매우 유사하다.¶

   struct {
       T1 f1;
       T2 f2;
       ...
       Tn fn;
   } T;

표준 목록 구문을 사용하여 고정 길이 및 가변 길이 목록(벡터) 필드를 사용할 수 있다. 변형 예(섹션 3.8)의 구조체 V1과 V2가 이를 보여준다.¶

열거형에 사용할 수 있는 것과 매우 유사한 구문으로, 형식 이름을 사용하여 구조체 내의 필드를 한정할 수 있다. 예를 들어 T.f2는 앞선 선언의 두 번째 필드를 가리킨다.¶

3.7. 상수

다음과 같이 "="를 사용하여 필드와 변수에 고정 값을 할당할 수 있다.¶

   struct {
       T1 f1 = 8;  /* T.f1은 항상 8이어야 함 */
       T2 f2;
   } T;

3.8. 변형

정의된 구조체는 환경 내에서 사용할 수 있는 일부 정보를 기반으로 변형을 가질 수 있다. 선택자는 구조체가 정의하는 가능한 변형을 정의하는 열거형이어야 한다. 아래 select의 각 분기는 해당 변형 필드의 형식과 선택적 필드 레이블을 지정한다. 런타임에 변형을 선택하는 메커니즘은 표현 언어에서 규정하지 않는다.¶

   struct {
       T1 f1;
       T2 f2;
       ....
       Tn fn;
       select (E) {
           case e1: Te1 [[fe1]];
           case e2: Te2 [[fe2]];
           ....
           case en: Ten [[fen]];
       };
   } Tv;

예를 들면 다음과 같다.¶

   enum { apple(0), orange(1) } VariantTag;

   struct {
       uint16 number;
       opaque string<0..10>; /* 가변 길이 */
   } V1;

   struct {
       uint32 number;
       opaque string[10];    /* 고정 길이 */
   } V2;

   struct {
       VariantTag type;
       select (VariantRecord.type) {
           case apple:  V1;
           case orange: V2;
       };
   } VariantRecord;

4.1. 트랜스크립트 해시

TLS의 많은 암호화 계산에서는 트랜스크립트 해시를 사용한다. 이 값은 핸드셰이크 메시지 유형과 길이 필드를 전달하는 핸드셰이크 메시지 헤더를 포함하되 레코드 계층 헤더는 포함하지 않고, 포함되는 각 핸드셰이크 메시지를 이어 붙인 값을 해시하여 계산한다. 즉,¶

 Transcript-Hash(M1, M2, ... Mn) = Hash(M1 || M2 || ... || Mn)

이 일반 규칙의 예외로, 서버가 ClientHello에 HelloRetryRequest로 응답하는 경우 ClientHello1의 값은 Hash(ClientHello1)을 포함하고 핸드셰이크 유형이 "message_hash"(254)인 특수 합성 핸드셰이크 메시지로 대체된다. 즉,¶

 Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) =
     Hash(message_hash ||        /* 핸드셰이크 유형 */
          00 00 Hash.length  ||  /* 핸드셰이크 메시지 길이(바이트) */
          Hash(ClientHello1) ||  /* ClientHello1의 해시 */
          HelloRetryRequest  || ... || Mn)

이 구성을 사용하는 이유는 서버가 전체 중간 해시 상태를 내보내지 않고 ClientHello1의 해시만 쿠키에 저장하여 상태 비저장 HelloRetryRequest를 수행할 수 있게 하기 위한 것이다 (섹션 4.3.2 참조).¶

메시지 범위를 "..."로 지정한 경우 트랜스크립트 해시는 기본 핸드셰이크 중 전송되거나 수신된 핸드셰이크 메시지의 시퀀스에서, 지정된 메시지로 시작하고 끝나는 범위를 대상으로 한다. 이 문서에서는 다음 핸드셰이크 메시지 시퀀스를 대상으로 한다 (일부는 생략될 수 있음): ClientHello, HelloRetryRequest, ClientHello, ServerHello, EncryptedExtensions, 서버 CertificateRequest, 서버 Certificate, 서버 CertificateVerify, 서버 Finished, EndOfEarlyData, 클라이언트 Certificate, 클라이언트 CertificateVerify 및 클라이언트 Finished. TLS 확장은 메시지를 추가하거나 제거할 수 있으며, 이 경우 트랜스크립트 해시는 수정된 시퀀스를 반영한다.¶

일반적으로 구현은 ServerHello에서 해시가 선택된 후, 협상된 해시를 기반으로 실행 중인 트랜스크립트 해시 값을 유지하여 트랜스크립트를 구현할 수 있다.¶

그러나 이후의 핸드셰이크 후 인증에는 서로가 포함되지 않으며, 기본 핸드셰이크가 끝날 때까지의 메시지만 포함된다는 점에 유의한다.¶

4.2. 키 교환 메시지

키 교환 메시지는 클라이언트와 서버의 보안 기능을 결정하고, 나머지 핸드셰이크와 데이터를 보호하는 데 사용되는 트래픽 키를 포함한 공유 비밀값을 설정하는 데 사용된다.¶

   uint16 ProtocolVersion;
   opaque Random[32];

   uint8 CipherSuite[2];    /* 암호 스위트 선택자 */

   struct {
       ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
       Random random;
       opaque legacy_session_id<0..32>;
       CipherSuite cipher_suites<2..2^16-2>;
       opaque legacy_compression_methods<1..2^8-1>;
       Extension extensions<7..2^16-1>;
   } ClientHello;

   struct {
       ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
       Random random;
       opaque legacy_session_id_echo<0..32>;
       CipherSuite cipher_suite;
       uint8 legacy_compression_method = 0;
       Extension extensions<6..2^16-1>;
   } ServerHello;

  CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91
  C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C

  44 4F 57 4E 47 52 44 01

  44 4F 57 4E 47 52 44 00

4.3. 확장

여러 TLS 메시지에는 태그-길이-값으로 인코딩된 확장 구조체가 포함된다.¶

   struct {
       ExtensionType extension_type;
       opaque extension_data<0..2^16-1>;
   } Extension;

   enum {
       server_name(0),                             /* RFC 6066, 9261 */
       status_request(5),                          /* RFC 6066, 9846 */
       supported_groups(10),                       /* RFC 7919, 9846 */
       signature_algorithms(13),                   /* RFC 9846 */
       use_srtp(14),                               /* RFC 5764 */
       heartbeat(15),                              /* RFC 6520 */
       application_layer_protocol_negotiation(16), /* RFC 7301 */
       client_certificate_type(19),                /* RFC 7250 */
       server_certificate_type(20),                /* RFC 7250 */
       padding(21),                                /* RFC 7685 */
       compress_certificate(27),                   /* RFC 8879 */
       record_size_limit(28),                      /* RFC 8449 */
       delegated_credential(34),                   /* RFC 9345 */
       supported_ekt_ciphers(39),                  /* RFC 8870 */
       pre_shared_key(41),                         /* RFC 9846 */
       early_data(42),                             /* RFC 9846 */
       supported_versions(43),                     /* RFC 9846 */
       cookie(44),                                 /* RFC 9846 */
       psk_key_exchange_modes(45),                 /* RFC 9846 */
       certificate_authorities(47),                /* RFC 9846 */
       oid_filters(48),                            /* RFC 9846 */
       post_handshake_auth(49),                    /* RFC 9846 */
       signature_algorithms_cert(50),              /* RFC 9846 */
       key_share(51),                              /* RFC 9846 */
       transparency_info(52),                      /* RFC 9162 */
       external_id_hash(55),                       /* RFC 8844 */
       external_session_id(56),                    /* RFC 8844 */
       quic_transport_parameters(57),              /* RFC 9001 */
       ticket_request(58),                         /* RFC 9149 */
       ech_outer_extensions(64768),                /* RFC 9849 */
       encrypted_client_hello(65037),              /* RFC 9849 */
       (65535)
   } ExtensionType;

참고: 이 목록에는 이 문서 작성 시점에 "권고"로 표시되고 TLS 1.3에서 허용된 확장만 포함된다.¶

여기에서:¶

• "extension_type"은 특정 확장 유형을 식별한다.¶

• "extension_data"는 특정 확장 유형에 해당하는 정보를 포함한다.¶

"extension_data" 필드의 내용은 일반적으로 TLS 표현 언어로 정의된 확장별 구조체에서 정의한다. 달리 명세하지 않는 한 후행 데이터는 금지된다. 즉, 송신자는 "extension_data" 필드의 구조체 뒤에 데이터를 포함해서는 안 된다. 확장을 처리할 때 구조체를 파싱한 후 데이터가 남아 있으면 수신자는 "decode_error" 경고와 함께 핸드셰이크를 반드시 중단해야 한다. 수신자가 해당 확장을 구현하지 않았거나 무시하도록 구성된 경우에는 적용되지 않는다.¶

확장 유형 목록은 섹션 11에 설명된 대로 IANA에서 관리한다.¶

확장은 일반적으로 요청/응답 방식으로 구성되지만, 일부 확장은 대응하는 응답이 없는 요청(즉, 표시)일 뿐이다. 클라이언트는 ClientHello 메시지에서 확장 요청을 전송하고, 서버는 ServerHello, EncryptedExtensions, HelloRetryRequest 및 Certificate 메시지에서 확장 응답을 전송한다. 서버는 CertificateRequest 메시지에서 확장 요청을 전송하며, 클라이언트는 Certificate 메시지로 응답할 수 있다. 서버는 NewSessionTicket에서 요청하지 않은 확장을 전송할 수도 있지만, 클라이언트는 이에 직접 응답하지 않는다.¶

원격 엔드포인트가 대응하는 확장 요청을 전송하지 않은 경우, 구현은 HelloRetryRequest의 "cookie" 확장을 제외하고 확장 응답(ServerHello, EncryptedExtensions, HelloRetryRequest 및 Certificate 메시지 안의 응답)을 전송해서는 안 된다. 이러한 확장을 수신하면 엔드포인트는 "unsupported_extension" 경고와 함께 핸드셰이크를 반드시 중단해야 한다.¶

아래 표는 각 확장이 나타날 수 있는 메시지를 다음 표기법으로 나타낸다: CH(ClientHello), SH(ServerHello), EE(EncryptedExtensions), CT(Certificate), CR(CertificateRequest), NST(NewSessionTicket), HRR(HelloRetryRequest). 구현이 인식하는 확장이 해당 확장에 대해 명세되지 않은 메시지에 나타난 경우 구현은 "illegal_parameter" 경고와 함께 핸드셰이크를 반드시 중단해야 한다.¶

참고: 이 표에는 이 문서 작성 시점에 "권고"로 표시되고 TLS 1.3에서 허용된 확장만 포함된다.¶

서로 다른 유형의 확장이 여러 개 존재하는 경우, ClientHello의 마지막 확장이어야 하는 "pre_shared_key"(섹션 4.3.11)를 제외하고 확장은 어떤 순서로든 나타날 수 있다 (ServerHello 확장 블록에서는 어디에나 나타날 수 있음). 특정 확장 블록에는 동일한 유형의 확장이 두 개 이상 있어서는 안 된다.¶

TLS 1.3에서는 TLS 1.2와 달리 재개-PSK 모드에서도 각 핸드셰이크마다 확장을 협상한다. 그러나 0-RTT 매개변수는 이전 핸드셰이크에서 협상된 것이며, 불일치하는 경우 0-RTT를 거부해야 할 수 있다(섹션 4.3.10 참조).¶

이 프로토콜에서는 새로운 기능과 기존 기능 사이에 미묘한 (때로는 명백한) 상호작용이 발생하여 전체 보안이 크게 저하될 수 있다. 새로운 확장을 설계할 때 다음 고려사항을 반영해야 한다.¶

• 서버가 확장에 동의하지 않는 일부 경우는 오류 조건 (예: 핸드셰이크를 계속할 수 없음)이고, 일부는 특정 기능 지원을 단순히 거부하는 경우이다. 일반적으로 전자에는 오류 경고를, 후자에는 서버 확장 응답의 필드를 사용해야 한다.¶

• 확장은 가능한 한 핸드셰이크 메시지를 조작하여 특정 기능을 사용하게 하거나 사용하지 못하게 하는 모든 공격을 방지하도록 설계해야 한다. 해당 기능이 보안 문제를 일으킨다고 여겨지는지와 관계없이 이 원칙을 따라야 한다. 확장 필드가 Finished 메시지 해시의 입력에 포함된다는 사실만으로 충분한 경우가 많지만, 확장이 핸드셰이크 단계에서 전송되는 메시지의 의미를 변경하는 경우에는 극도의 주의가 필요하다. 설계자와 구현자는 핸드셰이크가 인증되기 전까지 능동 공격자가 메시지를 수정하고 확장을 삽입, 제거 또는 교체할 수 있다는 사실을 인지해야 한다.¶

   struct {
       select (Handshake.msg_type) {
           case client_hello:
                ProtocolVersion versions<2..254>;

           case server_hello: /* 및 HelloRetryRequest */
                ProtocolVersion selected_version;
       };
   } SupportedVersions;

   struct {
       opaque cookie<1..2^16-1>;
   } Cookie;

   enum {
       /* RSASSA-PKCS1-v1_5 알고리즘 */
       rsa_pkcs1_sha256(0x0401),
       rsa_pkcs1_sha384(0x0501),
       rsa_pkcs1_sha512(0x0601),

       /* ECDSA 알고리즘 */
       ecdsa_secp256r1_sha256(0x0403),
       ecdsa_secp384r1_sha384(0x0503),
       ecdsa_secp521r1_sha512(0x0603),

       /* 공개 키 OID가 rsaEncryption인 RSASSA-PSS 알고리즘 */
       rsa_pss_rsae_sha256(0x0804),
       rsa_pss_rsae_sha384(0x0805),
       rsa_pss_rsae_sha512(0x0806),

       /* EdDSA 알고리즘 */
       ed25519(0x0807),
       ed448(0x0808),

       /* 공개 키 OID가 RSASSA-PSS인 RSASSA-PSS 알고리즘 */
       rsa_pss_pss_sha256(0x0809),
       rsa_pss_pss_sha384(0x080a),
       rsa_pss_pss_sha512(0x080b),

       /* 레거시 알고리즘 */
       rsa_pkcs1_sha1(0x0201),
       ecdsa_sha1(0x0203),

       /* 예약된 코드 포인트 */
       private_use(0xFE00..0xFFFF),
       (0xFFFF)
   } SignatureScheme;

   struct {
       SignatureScheme supported_signature_algorithms<2..2^16-2>;
   } SignatureSchemeList;

   opaque DistinguishedName<1..2^16-1>;

   struct {
       DistinguishedName authorities<3..2^16-1>;
   } CertificateAuthoritiesExtension;

   struct {
       opaque certificate_extension_oid<1..2^8-1>;
       opaque certificate_extension_values<0..2^16-1>;
   } OIDFilter;

   struct {
       OIDFilter filters<0..2^16-1>;
   } OIDFilterExtension;

   struct {} PostHandshakeAuth;

   enum {

       /* 타원 곡선 그룹(ECDHE) */
       secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
       x25519(0x001D), x448(0x001E),

       /* 유한체 그룹(DHE) */
       ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
       ffdhe6144(0x0103), ffdhe8192(0x0104),

       /* 예약된 코드 포인트 */
       ffdhe_private_use(0x01FC..0x01FF),
       ecdhe_private_use(0xFE00..0xFEFF),
       (0xFFFF)
   } NamedGroup;

   struct {
       NamedGroup named_group_list<2..2^16-1>;
   } NamedGroupList;

   struct {
       NamedGroup group;
       opaque key_exchange<1..2^16-1>;
   } KeyShareEntry;

   struct {
       KeyShareEntry client_shares<0..2^16-1>;
   } KeyShareClientHello;

   struct {
       NamedGroup selected_group;
   } KeyShareHelloRetryRequest;

   struct {
       KeyShareEntry server_share;
   } KeyShareServerHello;

   struct {
       uint8 legacy_form = 4;
       opaque X[coordinate_length];
       opaque Y[coordinate_length];
   } UncompressedPointRepresentation;

   enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;

   struct {
       PskKeyExchangeMode ke_modes<1..255>;
   } PskKeyExchangeModes;

   struct {} Empty;

   struct {
       select (Handshake.msg_type) {
           case new_session_ticket:   uint32 max_early_data_size;
           case client_hello:         Empty;
           case encrypted_extensions: Empty;
       };
   } EarlyDataIndication;

   struct {
       opaque identity<1..2^16-1>;
       uint32 obfuscated_ticket_age;
   } PskIdentity;

   opaque PskBinderEntry<32..255>;

   struct {
       PskIdentity identities<7..2^16-1>;
       PskBinderEntry binders<33..2^16-1>;
   } OfferedPsks;

   struct {
       select (Handshake.msg_type) {
           case client_hello: OfferedPsks;
           case server_hello: uint16 selected_identity;
       };
   } PreSharedKeyExtension;

   Transcript-Hash(Truncate(ClientHello1))

   Transcript-Hash(ClientHello1,
                   HelloRetryRequest,
                   Truncate(ClientHello2))

4.4. 서버 매개변수

서버의 다음 두 메시지인 EncryptedExtensions와 CertificateRequest에는 나머지 핸드셰이크를 결정하는 서버의 정보가 포함된다. 이 메시지는 server_handshake_traffic_secret에서 유도한 키로 암호화된다.¶

   struct {
       Extension extensions<0..2^16-1>;
   } EncryptedExtensions;

   struct {
       opaque certificate_request_context<0..2^8-1>;
       Extension extensions<0..2^16-1>;
   } CertificateRequest;

4.5. 인증 메시지

섹션 2에서 설명한 것처럼 TLS는 일반적으로 인증, 키 확인 및 핸드셰이크 무결성을 위해 Certificate, CertificateVerify 및 Finished라는 공통 메시지 집합을 사용한다. (PSK 바인더도 유사한 방식으로 키 확인을 수행한다.) 이 세 메시지는 항상 해당 핸드셰이크 플라이트의 마지막 메시지로 전송된다. Certificate 및 CertificateVerify 메시지는 아래에 정의된 특정 상황에서만 전송된다. Finished 메시지는 항상 인증 블록의 일부로 전송된다. 이러한 메시지는 핸드셰이크 후 인증을 제외하고 [sender]_handshake_traffic_secret에서 유도된 키로 암호화된다.¶

인증 메시지의 모든 계산에는 일관되게 다음 입력이 사용된다.¶

• 사용할 인증서와 서명 키.¶

• 트랜스크립트 해시에 포함할 메시지 목록으로 구성된 핸드셰이크 콘텍스트.¶

• MAC 키를 계산하는 데 사용할 기본 키.¶

이러한 입력을 기반으로 메시지는 다음을 포함한다.¶

Certificate:

인증에 사용할 인증서와 체인의 모든 지원 인증서. 인증서 기반 클라이언트 인증은 PSK 핸드셰이크 흐름 (0-RTT 포함)에서 사용할 수 없다는 점에 유의한다.¶

CertificateVerify:

Transcript-Hash(Handshake Context, Certificate) 값에 대한 서명.¶

Finished:

기본 키에서 유도된 MAC 키를 사용하여 Transcript-Hash(Handshake Context, Certificate, CertificateVerify) 값에 대해 계산한 MAC.¶

다음 표는 각 시나리오의 핸드셰이크 콘텍스트와 MAC 기본 키를 정의한다.¶

       enum {
           X509(0),
           RawPublicKey(2),
           (255)
       } CertificateType;

       struct {
           select (certificate_type) {
               case RawPublicKey:
                 /* RFC 7250의 ASN.1_subjectPublicKeyInfo */
                 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;

               case X509:
                 opaque cert_data<1..2^24-1>;
           };
           Extension extensions<0..2^16-1>;
       } CertificateEntry;

       struct {
           opaque certificate_request_context<0..2^8-1>;
           CertificateEntry certificate_list<0..2^24-1>;
       } Certificate;

   struct {
       SignatureScheme algorithm;
       opaque signature<0..2^16-1>;
   } CertificateVerify;

   Transcript-Hash(Handshake Context, Certificate)

   2020202020202020202020202020202020202020202020202020202020202020
   2020202020202020202020202020202020202020202020202020202020202020
   544c5320312e332c207365727665722043657274696669636174655665726966
   79
   00
   0101010101010101010101010101010101010101010101010101010101010101

finished_key =
    HKDF-Expand-Label(BaseKey, "finished", "", Hash.length)

   struct {
       opaque verify_data[Hash.length];
   } Finished;

   verify_data =
       HMAC(finished_key,
            Transcript-Hash(Handshake Context,
                            Certificate*, CertificateVerify*))

4.6. 초기 데이터 종료

   struct {} EndOfEarlyData;

서버가 EncryptedExtensions에서 "early_data" 확장을 전송한 경우, 클라이언트는 서버 Finished를 수신한 후 EndOfEarlyData 메시지를 반드시 전송해야 한다. 서버가 EncryptedExtensions에서 "early_data" 확장을 전송하지 않은 경우 클라이언트는 EndOfEarlyData 메시지를 전송해서는 안 된다. 이 메시지는 존재하는 모든 0-RTT application_data 메시지가 전송되었으며 이후 레코드가 핸드셰이크 트래픽 키로 보호됨을 나타낸다. 서버는 이 메시지를 전송해서는 안 되며, 이 메시지를 수신한 클라이언트는 "unexpected_message" 경고와 함께 연결을 반드시 종료해야 한다. 이 메시지는 client_early_traffic_secret에서 유도된 키로 암호화된다.¶

4.7. 핸드셰이크 후 메시지

TLS에서는 기본 핸드셰이크 후에 다른 메시지를 전송할 수도 있다. 이러한 메시지는 핸드셰이크 콘텐츠 유형을 사용하며 적절한 애플리케이션 트래픽 키로 암호화된다.¶

   struct {
       uint32 ticket_lifetime;
       uint32 ticket_age_add;
       opaque ticket_nonce<0..255>;
       opaque ticket<1..2^16-1>;
       Extension extensions<0..2^16-1>;
   } NewSessionTicket;

    HKDF-Expand-Label(resumption_secret,
                      "resumption", ticket_nonce, Hash.length)

   enum {
       update_not_requested(0), update_requested(1), (255)
   } KeyUpdateRequest;

   struct {
       KeyUpdateRequest request_update;
   } KeyUpdate;

5.1. 레코드 계층

레코드 계층은 정보 블록을 2¹⁴바이트 이하의 청크로 데이터를 전달하는 TLSPlaintext 레코드로 조각화한다. 메시지 경계는 기반 ContentType에 따라 다르게 처리된다. 향후 콘텐츠 유형은 적절한 규칙을 반드시 명세해야 한다. 이러한 규칙은 TLS 1.2에서 적용된 규칙보다 엄격하다는 점에 유의한다.¶

다음 조건을 충족하는 경우 핸드셰이크 메시지를 하나의 TLSPlaintext 레코드로 병합하거나 여러 레코드에 걸쳐 조각화할 수 있다.¶

• 핸드셰이크 메시지는 다른 레코드 유형과 번갈아 배치되어서는 안 된다. 즉, 하나의 핸드셰이크 메시지가 둘 이상의 레코드로 분할되면 그 사이에 다른 레코드가 있어서는 안 된다.¶

• 핸드셰이크 메시지는 키 변경에 걸쳐 있어서는 안 된다. 구현은 키 변경 직전의 모든 메시지가 레코드 경계와 정렬되는지 반드시 확인해야 하며, 그렇지 않으면 "unexpected_message" 경고와 함께 연결을 반드시 종료해야 한다. ClientHello, EndOfEarlyData, ServerHello, Finished 및 KeyUpdate 메시지는 키 변경 직전에 올 수 있으므로 구현은 이러한 메시지를 레코드 경계에 맞춰 반드시 전송해야 한다.¶

구현은 패딩이 포함된 경우에도 Handshake 유형의 길이가 0인 조각을 전송해서는 안 된다.¶

경고 메시지(섹션 6)는 여러 레코드에 걸쳐 조각화되어서는 안 되며, 여러 경고 메시지를 하나의 TLSPlaintext 레코드로 병합해서도 안 된다. 즉, Alert 유형의 레코드는 정확히 하나의 메시지를 반드시 포함해야 한다.¶

애플리케이션 데이터 메시지는 TLS에서 해석하지 않는 데이터를 포함한다. 애플리케이션 데이터 메시지는 항상 보호된다. 애플리케이션 데이터의 길이가 0인 조각 (즉, 콘텐츠 길이가 0인 application_data 유형의 TLSInnerPlaintext 레코드)은 트래픽 분석 대응책으로 잠재적으로 유용하므로 전송할 수 있다. 애플리케이션 데이터 조각은 여러 레코드에 걸쳐 분할하거나 하나의 레코드로 병합할 수 있다.¶

   enum {
       invalid(0),
       change_cipher_spec(20),
       alert(21),
       handshake(22),
       application_data(23),
       (255)
   } ContentType;

   struct {
       ContentType type;
       ProtocolVersion legacy_record_version;
       uint16 length;
       opaque fragment[TLSPlaintext.length];
   } TLSPlaintext;

type:

포함된 조각을 처리하는 데 사용되는 상위 수준 프로토콜.¶

legacy_record_version:

초기 ClientHello (즉, HelloRetryRequest 후에 생성되지 않은 ClientHello)를 제외하고 TLS 1.3 구현에서 생성하는 모든 레코드는 0x0303으로 반드시 설정해야 하며, 초기 ClientHello에서는 호환성 목적으로 0x0301일 수도 있다. 이 필드는 사용 중단되었으며 모든 목적으로 반드시 무시해야 한다. 이전 TLS 버전에서는 일부 상황에서 이 필드에 다른 값을 사용했다.¶

length:

뒤따르는 TLSPlaintext.fragment의 길이 (바이트 단위). 길이는 2¹⁴바이트를 초과해서는 안 된다. 이 길이를 초과하는 레코드를 수신한 엔드포인트는 "record_overflow" 경고와 함께 연결을 반드시 종료해야 한다.¶

fragment

전송되는 데이터. 이 값은 투명하며 type 필드에 지정된 상위 수준 프로토콜에서 처리할 독립적인 블록으로 취급된다.¶

이 문서는 버전 0x0304를 사용하는 TLS 1.3을 설명한다. 이 버전 값은 TLS 1.0에 0x0301, SSL 3.0에 0x0300을 사용한 데서 유래한 역사적인 값이다. 하위 호환성을 최대화하기 위해 초기 ClientHello가 포함된 레코드는 TLS 1.0을 나타내는 버전 0x0301을 사용하는 것이 권고되며, 두 번째 ClientHello 또는 ServerHello가 포함된 레코드는 TLS 1.2를 나타내는 버전 0x0303을 반드시 사용해야 한다. 이전 TLS 버전을 협상할 때 엔드포인트는 부록 E에 제시된 절차와 요구사항을 따른다.¶

레코드 보호가 아직 활성화되지 않은 경우 TLSPlaintext 구조체는 전송선에 직접 기록된다. 레코드 보호가 시작되면 TLSPlaintext 레코드는 다음 섹션에 설명된 대로 보호되어 전송된다. 애플리케이션 데이터 레코드는 보호되지 않은 상태로 전송선에 기록해서는 안 된다 (자세한 내용은 섹션 2 참조).¶

5.2. 레코드 페이로드 보호

레코드 보호 함수는 TLSPlaintext 구조체를 TLSCiphertext 구조체로 변환한다. 보호 해제 함수는 이 과정을 되돌린다. 이전 TLS 버전과 달리 TLS 1.3에서는 모든 암호를 "연관 데이터가 있는 인증된 암호화"(AEAD) [RFC5116]로 모델링한다. AEAD 함수는 평문을 인증된 암호문으로 변환하고 다시 되돌리는 통합 암호화 및 인증 연산을 제공한다. 암호화된 각 레코드는 평문 헤더와 그 뒤의 암호화된 본문으로 구성되며, 본문 자체에는 유형과 선택적 패딩이 포함된다.¶

   struct {
       opaque content[TLSPlaintext.length];
       ContentType type;
       uint8 zeros[length_of_padding];
   } TLSInnerPlaintext;

   struct {
       ContentType opaque_type = application_data; /* 23 */
       ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
       uint16 length;
       opaque encrypted_record[TLSCiphertext.length];
   } TLSCiphertext;

content:

핸드셰이크 또는 경고 메시지의 바이트 인코딩이나 전송할 애플리케이션 데이터의 원시 바이트를 포함하는 TLSPlaintext.fragment 값.¶

type:

레코드의 콘텐츠 유형을 포함하는 TLSPlaintext.type 값.¶

zeros:

type 필드 뒤의 평문에는 값이 0인 임의 길이의 연속 바이트가 나타날 수 있다. 이를 통해 송신자는 전체 크기가 레코드 크기 제한 이내에 있는 한 모든 TLS 레코드를 원하는 크기만큼 패딩할 수 있다. 자세한 내용은 섹션 5.4를 참조한다.¶

opaque_type:

이전 TLS 버전을 파싱하는 데 익숙한 미들박스와의 외부 호환성을 위해 TLSCiphertext 레코드의 외부 opaque_type 필드는 항상 값 23(application_data)으로 설정된다. 레코드의 실제 콘텐츠 유형은 복호화 후 TLSInnerPlaintext.type에서 찾을 수 있다.¶

legacy_record_version:

legacy_record_version 필드는 항상 0x0303이다. TLS 1.3 TLSCiphertext는 TLS 1.3이 협상된 후에야 생성되므로 다른 값을 수신할 수 있는 역사적 호환성 문제는 없다. ClientHello와 ServerHello 메시지를 포함한 핸드셰이크 프로토콜이 프로토콜 버전을 인증하므로 이 값은 중복된다는 점에 유의한다.¶

length:

뒤따르는 TLSCiphertext.encrypted_record의 길이(바이트 단위)이며, 콘텐츠와 패딩의 길이 합계에 내부 콘텐츠 유형을 위한 1바이트와 AEAD 알고리즘에서 추가된 확장량을 더한 값이다. 길이는 2¹⁴ + 256바이트를 초과해서는 안 된다. 이 길이를 초과하는 레코드를 수신한 엔드포인트는 "record_overflow" 경고와 함께 연결을 반드시 종료해야 한다.¶

encrypted_record:

직렬화된 TLSInnerPlaintext 구조체를 AEAD로 암호화한 형태.¶

AEAD 알고리즘은 [RFC5116]의 섹션 2.1에 설명된 대로 하나의 키, 논스, 평문 및 인증 검사에 포함할 "추가 데이터"를 입력으로 사용한다. 키는 client_write_key 또는 server_write_key이고, 논스는 시퀀스 번호와 client_write_iv 또는 server_write_iv에서 유도되며 (섹션 5.3 참조), 추가 데이터 입력은 레코드 헤더이다. 즉,¶

   additional_data = TLSCiphertext.opaque_type ||
                     TLSCiphertext.legacy_record_version ||
                     TLSCiphertext.length

AEAD 알고리즘에 입력되는 평문은 인코딩된 TLSInnerPlaintext 구조체이다. 트래픽 키 유도는 섹션 7.3에 정의되어 있다.¶

AEAD 출력은 AEAD 암호화 연산의 암호문 출력으로 구성된다. TLSInnerPlaintext.type과 송신자가 제공한 패딩이 포함되므로 평문의 길이는 대응하는 TLSPlaintext.length보다 크다. AEAD 출력의 길이는 일반적으로 평문보다 크지만 증가량은 AEAD 알고리즘에 따라 달라진다. 암호 자체에 패딩이 포함될 수 있으므로 오버헤드의 양은 평문 길이에 따라 달라질 수 있다. 기호로 나타내면 다음과 같다.¶

   AEADEncrypted =
       AEAD-Encrypt(write_key, nonce, additional_data, plaintext)

TLSCiphertext의 encrypted_record 필드는 AEADEncrypted로 설정한다.¶

복호화하고 검증하기 위해 암호는 키, 논스, 추가 데이터 및 AEADEncrypted 값을 입력으로 사용한다. 출력은 평문 또는 복호화 실패를 나타내는 오류이다. 별도의 무결성 검사는 없다. 기호로 나타내면 다음과 같다.¶

 plaintext of encrypted_record =
     AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted)

복호화에 실패하면 수신자는 "bad_record_mac" 경고와 함께 연결을 반드시 종료해야 한다.¶

TLS 1.3에서 사용하는 AEAD 알고리즘은 255옥텟보다 큰 확장량을 생성해서는 안 된다. 피어로부터 TLSCiphertext.length가 2¹⁴ + 256옥텟보다 큰 레코드를 수신한 엔드포인트는 "record_overflow" 경고와 함께 연결을 반드시 종료해야 한다. 이 제한은 최대 TLSInnerPlaintext 길이인 2¹⁴옥텟, ContentType을 위한 1옥텟 및 최대 AEAD 확장량인 255옥텟에서 도출된다.¶

5.3. 레코드별 논스

레코드를 읽고 쓰기 위한 64비트 시퀀스 번호를 별도로 유지한다. 각 레코드를 읽거나 쓴 후 해당 시퀀스 번호를 1씩 증가시킨다. 각 시퀀스 번호는 연결 시작 시와 키가 변경될 때마다 0으로 설정되며, 특정 트래픽 키로 전송되는 첫 번째 레코드는 시퀀스 번호 0을 반드시 사용해야 한다.¶

시퀀스 번호의 크기가 64비트이므로 순환해서는 안 된다. TLS 구현에서 시퀀스 번호를 순환해야 하는 경우 키를 다시 설정하거나 (섹션 4.7.3) 연결을 반드시 종료해야 한다.¶

각 AEAD 알고리즘은 레코드별 논스에 허용되는 입력 길이 범위를 N_MIN바이트에서 N_MAX바이트까지 지정한다 [RFC5116]. TLS 레코드별 논스의 길이(iv_length)는 8바이트와 AEAD 알고리즘의 N_MIN 중 더 큰 값으로 설정한다 ([RFC5116], 섹션 4 참조). N_MAX가 8바이트보다 작은 AEAD 알고리즘은 TLS와 함께 사용해서는 안 된다. AEAD 구성의 레코드별 논스는 다음과 같이 형성한다.¶

1. 64비트 레코드 시퀀스 번호를 네트워크 바이트 순서로 인코딩하고 iv_length가 되도록 왼쪽을 0으로 패딩한다.¶

2. 패딩된 시퀀스 번호를 역할에 따라 정적 client_write_iv 또는 server_write_iv와 XOR한다.¶

그 결과 얻은 iv_length 길이의 값을 레코드별 논스로 사용한다.¶

참고: 이는 일부가 명시적인 논스를 지정한 TLS 1.2의 구성과 다르다.¶

5.4. 레코드 패딩

암호화된 모든 TLS 레코드는 TLSCiphertext의 크기를 늘리기 위해 패딩할 수 있다. 이를 통해 송신자는 관찰자에게 트래픽의 크기를 숨길 수 있다.¶

TLSCiphertext 레코드를 생성할 때 구현은 패딩을 선택할 수 있다. 패딩되지 않은 레코드는 패딩 길이가 0인 레코드일 뿐이다. 패딩은 암호화 전에 ContentType 필드 뒤에 추가되는 값이 0인 바이트 문자열이다. 구현은 암호화하기 전에 모든 패딩 옥텟을 0으로 반드시 설정해야 한다.¶

송신자가 원하는 경우 애플리케이션 데이터 레코드는 길이가 0인 TLSInnerPlaintext.content를 포함할 수 있다. 이를 통해 활동의 유무가 민감할 수 있는 콘텍스트에서 그럴듯한 크기의 위장 트래픽을 생성할 수 있다. 구현은 길이가 0인 TLSInnerPlaintext.content를 가진 Handshake 및 Alert 레코드를 전송해서는 안 된다. 이러한 메시지를 수신한 구현은 "unexpected_message" 경고와 함께 연결을 반드시 종료해야 한다.¶

전송된 패딩은 레코드 보호 메커니즘에서 자동으로 검증된다. TLSCiphertext.encrypted_record를 성공적으로 복호화하면 수신 구현은 0이 아닌 옥텟을 찾을 때까지 필드를 끝에서 시작 방향으로 검색한다. 이 0이 아닌 옥텟이 메시지의 콘텐츠 유형이다. 이 패딩 방식은 새로운 콘텐츠 유형을 도입하지 않고도 암호화된 모든 TLS 레코드를 0부터 TLS 레코드 크기 제한까지 임의의 크기로 패딩할 수 있으므로 선택되었다. 이 설계는 모든 패딩 옥텟을 0으로 제한하므로 패딩 오류를 빠르게 탐지할 수도 있다.¶

구현은 검색 범위를 AEAD 복호화에서 반환된 평문으로 반드시 제한해야 한다. 수신 구현이 평문에서 0이 아닌 옥텟을 찾지 못하면 "unexpected_message" 경고와 함께 연결을 반드시 종료해야 한다.¶

패딩이 있어도 전체 레코드 크기 제한은 변경되지 않는다. 인코딩된 전체 TLSInnerPlaintext는 2¹⁴ + 1옥텟을 초과해서는 안 된다. 예를 들어 [RFC8449]의 record_size_limit 확장에 의해 최대 조각 길이가 감소하면, 감소된 제한은 콘텐츠 유형과 패딩을 포함한 전체 평문에 적용된다.¶

패딩 시점과 패딩량을 결정하는 패딩 정책을 선택하는 것은 복잡한 주제이며 이 명세의 범위를 벗어난다. TLS 위의 애플리케이션 계층 프로토콜에 자체 패딩이 있는 경우 애플리케이션 계층에서 애플리케이션 데이터 TLS 레코드를 패딩하는 편이 더 바람직할 수 있다. 그러나 암호화된 Handshake 또는 Alert 레코드의 패딩은 여전히 TLS 계층에서 처리해야 한다. 향후 문서에서 패딩 선택 알고리즘을 정의하거나 TLS 확장 또는 다른 수단을 통한 패딩 정책 요청 메커니즘을 정의할 수 있다.¶

5.5. 키 사용 제한

특정 키 집합으로 안전하게 암호화할 수 있는 평문의 양에는 암호학적 제한이 있다. [AEAD-LIMITS]는 기반 프리미티브 (AES 또는 ChaCha20)에 약점이 없다고 가정하여 이러한 제한을 분석한다. 구현은 이러한 제한에 도달하기 전에 연결을 닫거나 섹션 4.7.3에 설명된 대로 키 갱신을 반드시 수행해야 한다. 초기 데이터에는 KeyUpdate를 수행할 수 없으므로 구현은 초기 데이터를 전송할 때 이 제한을 초과해서는 안 된다. 향후 분석에서 값이 갱신될 수 있으므로 수신 구현은 이러한 제한을 강제하지 않는 것이 권고된다.¶

AES-GCM의 경우 인증된 암호화(AE) 보안에 대해 약 2^-57의 안전 여유를 유지하면서 특정 키 집합으로 최대 2^24.5개의 최대 크기 레코드 (약 2,400만 개)를 암호화할 수 있다. ChaCha20/Poly1305의 경우 안전 제한에 도달하기 전에 레코드 시퀀스 번호가 순환한다.¶

6.1. 종료 경고

잘라내기 공격을 방지하려면 클라이언트와 서버가 연결이 종료되고 있음을 서로 알고 있어야 한다.¶

close_notify:

이 경고는 송신자가 이 연결에서 더 이상 메시지를 전송하지 않을 것임을 수신자에게 알린다. 종료 경고를 수신한 후 수신되는 모든 데이터는 반드시 무시해야 한다. 이 경고는 AlertLevel=warning으로 반드시 전송해야 한다.¶

user_canceled:

이 경고는 송신자가 프로토콜 실패와 관련 없는 어떤 이유로 핸드셰이크를 취소하고 있음을 수신자에게 알린다. 핸드셰이크가 완료된 후 사용자가 작업을 취소하는 경우에는 "close_notify"를 전송하여 연결을 닫는 것이 더 적절하다. 이 경고 뒤에는 "close_notify"가 반드시 와야 한다. 이 경고의 AlertLevel은 일반적으로 warning이다. 수신 구현은 "close_notify"를 수신할 때까지 피어에서 데이터를 계속 읽는 것이 권고되지만, 이를 로그에 남기거나 다른 방식으로 기록할 수 있다.¶

어느 쪽이든 "close_notify" 경고를 전송하여 연결의 쓰기 측 종료를 시작할 수 있다. "close_notify"보다 먼저 전송 계층 종료를 수신하면 수신자는 전송된 모든 데이터를 수신했는지 알 수 없다.¶

각 당사자는 이미 오류 경고를 전송한 경우를 제외하고 연결의 쓰기 측을 닫기 전에 "close_notify" 경고를 반드시 전송해야 한다. 이는 연결의 읽기 측에는 영향을 미치지 않는다. 이는 구현이 "close_notify"에 반응하여 대기 중인 쓰기를 폐기하고 즉시 자체 "close_notify" 경고를 전송해야 했던 TLS 1.3 이전 버전과 달라진 사항이다. 이전 요구사항은 읽기 측에서 잘라내기를 일으킬 수 있었다. 양쪽 모두 연결의 읽기 측을 닫기 전에 "close_notify" 경고를 수신할 때까지 기다릴 필요는 없지만, 기다리지 않으면 잘라내기가 발생할 가능성이 생긴다.¶

애플리케이션 프로토콜은 "close_notify"를 수신하면 송신 버퍼를 비우고 즉시 "close_notify"를 전송하도록 선택할 수 있지만, 이 경우 공격자가 "close_notify"나 애플리케이션 패킷의 전송 계층 전달을 지연시켜 피어가 수신하는 데이터에 영향을 줄 수 있다. 이러한 문제는 예를 들어 "close_notify"를 전송한 후 수신되는 패킷을 무시하는 방식으로 애플리케이션 계층에서 해결할 수 있다.¶

TLS를 사용하는 애플리케이션 프로토콜에서 TLS 연결이 닫힌 후에도 기반 전송을 통해 데이터를 전달할 수 있도록 하는 경우, TLS 구현은 애플리케이션 계층에 데이터 종료를 알리기 전에 "close_notify" 경고를 반드시 수신해야 한다. 연결을 열거나 닫는 시점을 포함하여 TLS 사용 프로필이 데이터 전송을 관리하는 방식을 이 표준의 어떤 부분도 규정하는 것으로 해석해서는 안 된다.¶

참고: 연결의 쓰기 측을 닫으면 전송을 폐기하기 전에 대기 중인 데이터가 신뢰성 있게 전달된다고 가정한다.¶

6.2. 오류 경고

TLS의 오류 처리는 매우 간단하다. 오류가 탐지되면 이를 탐지한 쪽이 피어에 메시지를 전송한다. 치명적 경고 메시지를 전송하거나 수신하면 양쪽 모두 즉시 연결을 반드시 닫아야 한다.¶

구현이 치명적 오류 조건을 만날 때마다 적절한 치명적 경고를 전송하는 것이 권고되며, 추가 데이터를 송수신하지 않고 연결을 반드시 닫아야 한다. 이 명세 전체에서 특정 경고 없이 "연결을 종료한다" 또는 "핸드셰이크를 중단한다"라는 표현을 사용하면 구현이 아래 설명에 지정된 경고를 전송하는 것이 권고된다는 의미이다. "X 경고와 함께 연결을 종료한다" 또는 "X 경고와 함께 핸드셰이크를 중단한다"라는 표현은 구현이 경고를 전송하는 경우 X 경고를 반드시 전송해야 한다는 의미이다. 이 섹션에서 아래에 정의된 모든 경고와 알 수 없는 모든 경고는 TLS 1.3부터 보편적으로 치명적 경고로 간주된다 (섹션 6 참조). 구현은 경고 송수신을 기록하기 위한 방법을 제공하는 것이 권고된다.¶

다음 오류 경고를 정의한다.¶

unexpected_message:

부적절한 메시지 (예: 잘못된 핸드셰이크 메시지, 너무 이른 애플리케이션 데이터 등)를 수신했다. 올바른 구현 간 통신에서는 이 경고가 절대로 나타나서는 안 된다.¶

bad_record_mac:

보호를 해제할 수 없는 레코드를 수신하면 이 경고를 반환한다. AEAD 알고리즘은 복호화와 검증을 결합하며 부채널 공격을 방지해야 하므로, 모든 보호 해제 실패에 이 경고를 사용한다. 네트워크에서 메시지가 손상된 경우를 제외하면 올바른 구현 간 통신에서는 이 경고가 절대로 나타나서는 안 된다.¶

record_overflow:

길이가 2¹⁴ + 256바이트보다 큰 TLSCiphertext 레코드를 수신했거나, 복호화한 결과 2¹⁴바이트 (또는 협상된 다른 제한)보다 큰 TLSPlaintext 레코드가 되었다. 네트워크에서 메시지가 손상된 경우를 제외하면 올바른 구현 간 통신에서는 이 경고가 절대로 나타나서는 안 된다.¶

handshake_failure:

"handshake_failure" 경고 메시지를 수신했다는 것은 송신자가 사용 가능한 옵션으로 허용 가능한 보안 매개변수 집합을 협상할 수 없었음을 나타낸다.¶

bad_certificate:

인증서가 손상되었거나 올바르게 검증되지 않는 서명이 포함되어 있는 등의 경우.¶

unsupported_certificate:

인증서 유형이 지원되지 않는다.¶

certificate_revoked:

인증서가 서명자에 의해 폐기되었다.¶

certificate_expired:

인증서가 만료되었거나 현재 유효하지 않다.¶

certificate_unknown:

인증서 처리 중 다른 명시되지 않은 문제가 발생하여 인증서를 수락할 수 없다.¶

illegal_parameter:

핸드셰이크의 필드가 잘못되었거나 다른 필드와 일관되지 않는다. 이 경고는 형식적 프로토콜 구문에는 부합하지만 그 밖의 측면에서 올바르지 않은 오류에 사용된다.¶

unknown_ca:

유효한 인증서 체인 또는 부분 체인을 수신했지만, CA 인증서를 찾을 수 없거나 알려진 신뢰 앵커와 일치시킬 수 없어 인증서를 수락하지 않았다.¶

access_denied:

유효한 인증서 또는 PSK를 수신했지만 접근 제어를 적용한 결과 송신자가 협상을 진행하지 않기로 결정했다.¶

decode_error:

일부 필드가 지정된 범위를 벗어났거나 메시지 길이가 올바르지 않아 메시지를 디코딩할 수 없다. 이 경고는 메시지가 형식적 프로토콜 구문에 부합하지 않는 오류에 사용된다. 네트워크에서 메시지가 손상된 경우를 제외하면 올바른 구현 간 통신에서는 이 경고가 절대로 나타나서는 안 된다.¶

decrypt_error:

서명을 올바르게 검증하지 못하거나 Finished 메시지 또는 PSK 바인더를 검증하지 못하는 경우를 포함하여, 핸드셰이크의 암호화 연산 (레코드 계층 연산 제외)이 실패했다.¶

protocol_version:

피어가 협상하려고 시도한 프로토콜 버전을 인식하지만 지원하지 않는다 (부록 E 참조).¶

insufficient_security:

서버가 클라이언트에서 지원하는 것보다 더 안전한 매개변수를 요구하여 협상이 실패한 경우 "handshake_failure" 대신 반환된다.¶

internal_error:

피어나 프로토콜의 정확성과 관련 없는 내부 오류 (예: 메모리 할당 실패) 때문에 계속 진행할 수 없다.¶

inappropriate_fallback:

클라이언트의 유효하지 않은 연결 재시도에 대한 응답으로 서버가 전송한다 ([RFC7507] 참조).¶

missing_extension:

제공된 TLS 버전 또는 다른 협상된 매개변수에서 전송이 필수인 확장을 포함하지 않은 핸드셰이크 메시지를 수신한 엔드포인트가 전송한다.¶

unsupported_extension:

대응하는 ClientHello 또는 CertificateRequest에서 먼저 제공하지 않은 확장을 ServerHello, HelloRetryRequest, EncryptedExtensions 또는 Certificate에 포함한 핸드셰이크 메시지를 수신한 엔드포인트가 전송한다.¶

unrecognized_name:

클라이언트가 "server_name" 확장을 통해 제공한 이름으로 식별되는 서버가 존재하지 않을 때 서버가 전송한다 ([RFC6066] 참조).¶

bad_certificate_status_response:

서버가 "status_request" 확장을 통해 유효하지 않거나 수락할 수 없는 OCSP 응답을 제공한 경우 클라이언트가 전송한다 ([RFC6066] 참조).¶

unknown_psk_identity:

PSK 키 설정을 원하지만 클라이언트가 허용 가능한 PSK 식별자를 제공하지 않은 경우 서버가 전송한다. 이 경고를 전송하는 것은 선택 사항이며, 서버는 유효하지 않은 PSK 식별자임만 나타내기 위해 "decrypt_error" 경고를 대신 전송하도록 선택할 수 있다.¶

certificate_required:

클라이언트 인증서가 필요하지만 클라이언트가 인증서를 제공하지 않은 경우 서버가 전송한다.¶

general_error:

더 구체적인 오류가 없거나 송신자가 구체적인 오류 코드를 숨기려는 경우 오류 조건을 나타내기 위해 전송한다. 구현은 가능한 경우 더 구체적인 오류를 사용하는 것이 권고된다.¶

no_application_protocol:

클라이언트의 "application_layer_protocol_negotiation" 확장이 서버가 지원하지 않는 프로토콜만 알리는 경우 서버가 전송한다 ([RFC7301] 참조).¶

새로운 Alert 값은 섹션 11에 설명된 대로 IANA가 할당한다.¶

7.1. 키 스케줄

키 유도 과정에서는 HKDF [RFC5869]에 정의된 HKDF-Extract 및 HKDF-Expand 함수와 아래에 정의된 함수를 사용한다.¶

    HKDF-Expand-Label(Secret, Label, Context, Length) =
         HKDF-Expand(Secret, HkdfLabel, Length)

여기에서 HkdfLabel은 다음과 같이 지정한다.¶

    struct {
        uint16 length = Length;
        opaque label<7..255> = "tls13 " + Label;
        opaque context<0..255> = Context;
    } HkdfLabel;

    Derive-Secret(Secret, Label, Messages) =
         HKDF-Expand-Label(Secret, Label,
                           Transcript-Hash(Messages), Hash.length)

Transcript-Hash와 HKDF에서 사용하는 Hash 함수는 암호 스위트의 해시 알고리즘이다. Hash.length는 해당 출력의 바이트 단위 길이이다. Messages는 핸드셰이크 메시지 유형과 길이 필드를 포함하되 레코드 계층 헤더는 포함하지 않은, 표시된 핸드셰이크 메시지를 이어 붙인 값이다. 일부 경우 길이가 0인 Context (""로 표시됨)가 HKDF-Expand-Label에 전달된다는 점에 유의한다. 이 문서에 지정된 레이블은 모두 ASCII 문자열이며 후행 NUL 바이트를 포함하지 않는다.¶

"HKDF-Expand-Label"을 사용하는 TLS 확장은 해당 확장을 함께 사용하는 TLS 버전에 연결된 HkdfLabel 정의를 사용한다. 이 명세와 함께 사용하는 경우 위에 정의된 HkdfLabel을 사용하며, DTLS [RFC9147]와 함께 사용하는 경우 [RFC9147], 섹션 5.9에 정의된 버전을 사용한다.¶

참고: 일반적인 해시 함수에서는 12자보다 긴 레이블을 계산하려면 해시 함수를 한 번 더 반복해야 한다. 이 명세의 모든 레이블은 이 제한 안에 들어가도록 선택되었다.¶

키는 HKDF-Extract 및 Derive-Secret 함수를 사용해 두 입력 비밀값에서 유도한다. 새 비밀값을 추가하는 일반적인 방식은 현재 비밀 상태를 Salt로, 새로 추가할 비밀값을 입력 키 자료(IKM)로 하여 HKDF-Extract를 사용하는 것이다. 이 TLS 1.3 버전에서 두 입력 비밀값은 다음과 같다.¶

• PSK (외부에서 설정되거나 이전 연결의 resumption_secret 값에서 유도된 사전 공유 키)¶

• 비대칭 키 설정의 결과로 얻은 비대칭 공유 비밀값 (섹션 7.4 참조)¶

이로부터 아래 다이어그램 (그림 5)에 표시된 키 스케줄이 생성된다. 이 다이어그램에는 다음 형식 규칙이 적용된다.¶

• HKDF-Extract는 위쪽에서 Salt 인수를, 왼쪽에서 IKM 인수를 받고, 출력은 아래쪽에, 출력 이름은 오른쪽에 표시한다.¶

• Derive-Secret의 Secret 인수는 들어오는 화살표로 표시한다. 예를 들어 Early Secret은 client_early_traffic_secret을 생성하는 Secret이다.¶

• "0"은 값이 0으로 설정된 Hash.length바이트 문자열을 나타낸다.¶

참고: 값은 "main" 비밀값이라고 부르지만 키 유도 레이블에는 "master" 문자열을 사용한다. 이 불일치는 호환성을 유지하면서 값의 이름을 변경한 결과이다.¶

참고: 여기에는 별도의 AEAD 키와 IV 키 같은 모든 말단 키가 표시된 것이 아니라 핸드셰이크에서 유도된 첫 번째 비밀값 집합이 표시되어 있다.¶

                 0
                 |
                 v
     PSK -->  HKDF-Extract = 초기 비밀값
                 |
                 +-----> Derive-Secret(.,
                 |                     "ext binder" |
                 |                     "res binder",
                 |                     "")
                 |              = binder_key
                 |
                 +-----> Derive-Secret(., "c e traffic",
                 |                     ClientHello)
                 |              = client_early_traffic_secret
                 |
                 +-----> Derive-Secret(., "e exp master",
                 |                     ClientHello)
                 |              = early_exporter_secret
                 v
            Derive-Secret(., "derived", "")
                 |
    비대칭       v
   공유 비밀값 --> HKDF-Extract = 핸드셰이크 비밀값
                 |
                 +-----> Derive-Secret(., "c hs traffic",
                 |                     ClientHello...ServerHello)
                 |              = client_handshake_traffic_secret
                 |
                 +-----> Derive-Secret(., "s hs traffic",
                 |                     ClientHello...ServerHello)
                 |              = server_handshake_traffic_secret
                 v
            Derive-Secret(., "derived", "")
                 |
                 v
        0 --> HKDF-Extract = 주 비밀값
                 |
                 +-----> Derive-Secret(., "c ap traffic",
                 |                     ClientHello...서버 Finished)
                 |              = client_application_traffic_secret_0
                 |
                 +-----> Derive-Secret(., "s ap traffic",
                 |                     ClientHello...서버 Finished)
                 |              = server_application_traffic_secret_0
                 |
                 +-----> Derive-Secret(., "exp master",
                 |                     ClientHello...서버 Finished)
                 |              = exporter_secret
                 |
                 +-----> Derive-Secret(., "res master",
                                       ClientHello...클라이언트 Finished)
                                = resumption_secret

여기에서 일반적인 방식은 다이어그램 왼쪽에 표시된 비밀값은 콘텍스트가 없는 원시 엔트로피이고, 오른쪽에 표시된 비밀값은 핸드셰이크 콘텍스트를 포함하므로 추가 콘텍스트 없이 실제 키를 유도하는 데 사용할 수 있다는 것이다. 동일한 비밀값을 사용하더라도 Derive-Secret 호출마다 서로 다른 Messages 인수를 사용할 수 있다는 점에 유의한다. 0-RTT 교환에서 Derive-Secret은 서로 다른 네 개의 트랜스크립트로 호출되며, 1-RTT 전용 교환에서는 서로 다른 세 개의 트랜스크립트로 호출된다.¶

특정 비밀값을 사용할 수 없는 경우 값이 0으로 설정된 Hash.length바이트 문자열로 구성된 0 값을 사용한다. 이는 단계를 건너뛴다는 의미가 아니므로 PSK를 사용하지 않더라도 Early Secret은 여전히 HKDF-Extract(0, 0)이 된다. binder_key 계산에서 외부 PSK (TLS 외부에서 프로비저닝됨)에는 "ext binder" 레이블을, 재개 PSK(이전 핸드셰이크의 재개 비밀값으로 프로비저닝됨)에는 "res binder" 레이블을 사용한다. 서로 다른 레이블은 한 PSK 유형을 다른 유형으로 대체하는 것을 방지한다.¶

서버가 최종적으로 선택하는 PSK에 따라 가능한 Early Secret 값이 여러 개 있다. 클라이언트는 가능한 각 PSK에 대해 하나씩 계산해야 하며, PSK가 선택되지 않으면 0 PSK에 대응하는 Early Secret도 계산해야 한다.¶

특정 비밀값에서 유도할 모든 값을 계산한 후에는 해당 비밀값을 삭제하는 것이 권고된다.¶

7.2. 트래픽 비밀값 갱신

핸드셰이크가 완료되면 어느 쪽이든 섹션 4.7.3에 정의된 KeyUpdate 핸드셰이크 메시지를 사용해 송신 트래픽 키를 갱신할 수 있다. 다음 세대의 트래픽 키는 이 섹션에 설명된 대로 client_/server_application_traffic_secret_N에서 client_/server_application_traffic_secret_N+1을 생성한 후, 섹션 7.3에 설명된 대로 트래픽 키를 다시 유도하여 계산한다.¶

다음 세대 application_traffic_secret은 다음과 같이 계산한다.¶

    application_traffic_secret_N+1 =
        HKDF-Expand-Label(application_traffic_secret_N,
                          "traffic upd", "", Hash.length)

client_/server_application_traffic_secret_N+1과 연관된 트래픽 키를 계산한 후 구현은 client_/server_application_traffic_secret_N과 연관된 트래픽 키를 삭제하는 것이 권고된다.¶

7.3. 트래픽 키 계산

트래픽 키 자료는 다음 입력 값에서 생성한다.¶

• 비밀값¶

• 생성 중인 특정 값을 나타내는 용도 값¶

• 생성 중인 키의 길이¶

트래픽 키 자료는 입력 트래픽 비밀값에서 다음을 사용해 생성한다.¶

[sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length)
[sender]_write_iv  = HKDF-Expand-Label(Secret, "iv", "", iv_length)

[sender]는 송신 측을 나타낸다. 각 데이터 범주의 Secret 값은 아래 표에 표시되어 있다.¶

경고는 당시의 현재 송신 키 (그러한 키가 설정되지 않은 경우 평문)를 사용해 전송한다. 기반 Secret이 변경될 때마다 (예: 핸드셰이크 키에서 애플리케이션 데이터 키로 변경하거나 키를 갱신할 때) 모든 트래픽 키 자료를 다시 계산한다.¶

7.4. 비대칭 공유 비밀값 계산

7.5. 익스포터

[RFC5705]는 TLS 의사 난수 함수(PRF)를 기준으로 TLS용 키 자료 익스포터를 정의한다. 이 문서는 PRF를 HKDF로 대체하므로 새로운 구성이 필요하다. 익스포터 인터페이스는 동일하게 유지된다.¶

익스포터 값은 다음과 같이 계산한다.¶

TLS-Exporter(label, context_value, key_length) =
    HKDF-Expand-Label(Derive-Secret(Secret, label, ""),
                      "exporter", Hash(context_value), key_length)

여기에서 Secret은 early_exporter_secret 또는 exporter_secret이다. 애플리케이션이 명시적으로 지정하지 않는 한 구현은 exporter_secret을 반드시 사용해야 한다. early_exporter_secret은 0-RTT 데이터에 익스포터가 필요한 상황에서 사용하도록 정의되어 있다. 초기 익스포터에는 별도의 인터페이스를 사용하는 것이 권고된다. 이렇게 하면 익스포터 사용자가 일반 익스포터를 원할 때 실수로 초기 익스포터를 사용하거나 그 반대의 경우를 방지할 수 있다.¶

콘텍스트를 제공하지 않으면 context_value의 길이는 0이다. 따라서 콘텍스트를 제공하지 않은 경우와 빈 콘텍스트를 제공한 경우는 동일한 값을 계산한다. 이는 빈 콘텍스트가 콘텍스트가 없는 경우와 다른 출력을 생성했던 이전 TLS 버전에서 변경된 사항이다. 이 문서 발행 시점에는 할당된 어떤 익스포터 레이블도 콘텍스트가 있는 경우와 없는 경우 모두에 사용되지 않는다. 향후 명세는 동일한 레이블에서 빈 콘텍스트와 콘텍스트 없음이 모두 허용되는 익스포터 사용을 정의해서는 안 된다. 새로운 익스포터 사용은 값이 비어 있을 수 있더라도 모든 익스포터 계산에 콘텍스트를 제공하는 것이 권고된다.¶

익스포터 레이블 형식의 요구사항은 [RFC5705]의 섹션 4에 정의되어 있다.¶

8.1. 일회용 티켓

가장 단순한 재전송 방지 방식은 서버가 각 세션 티켓을 한 번만 사용하도록 허용하는 것이다. 예를 들어 서버는 아직 사용되지 않은 모든 유효한 티켓의 데이터베이스를 유지하고 각 티켓이 사용되면 데이터베이스에서 삭제할 수 있다. 알 수 없는 티켓이 제공되면 서버는 전체 핸드셰이크로 대체한다.¶

티켓이 자체 포함형이 아니라 데이터베이스 키이고 대응하는 PSK가 사용 시 삭제되는 경우, PSK를 사용해 설정된 연결은 재전송 방지뿐 아니라 데이터베이스 항목에서 PSK의 모든 복사본이 삭제된 후 순방향 비밀성도 얻는다. 이 메커니즘은 비대칭 키 교환 없이 PSK를 사용할 때의 PSK 사용 보안도 향상한다.¶

이 메커니즘은 여러 분산 서버가 있는 환경에서 서버 노드 간 세션 데이터베이스를 공유해야 하므로, 자체 암호화 티켓과 비교하면 성공적인 PSK 0-RTT 연결 비율을 높이기 어려울 수 있다. 세션 데이터베이스와 달리 세션 티켓은 일관된 저장소가 없어도 PSK 기반 세션 설정을 성공적으로 수행할 수 있지만, 0-RTT를 허용하는 경우에는 다음 섹션에 설명된 대로 0-RTT 데이터의 재전송 방지를 위해 여전히 일관된 저장소가 필요하다.¶

8.2. 클라이언트 헬로 기록

다른 재전송 방지 방식은 ClientHello에서 유도된 고유한 값 (일반적으로 random 값 또는 PSK 바인더)을 기록하고 중복을 거부하는 것이다. 모든 ClientHello를 기록하면 상태가 무한히 증가하지만, 서버는 대신 특정 시간 창 안의 ClientHello만 기록하고 "obfuscated_ticket_age"를 사용하여 티켓이 해당 시간 창 밖에서 재사용되지 않도록 보장할 수 있다.¶

이를 구현하려면 서버는 ClientHello를 수신할 때 먼저 섹션 4.3.11에 설명된 대로 PSK 바인더를 검증한다. 그런 다음 다음 섹션에 설명된 대로 expected_arrival_time을 계산하고 기록 시간 창 밖에 있으면 0-RTT를 거부하여 1-RTT 핸드셰이크로 대체한다.¶

expected_arrival_time이 시간 창 안에 있으면 서버는 일치하는 ClientHello를 기록했는지 확인한다. 일치하는 항목을 찾으면 "illegal_parameter" 경고와 함께 핸드셰이크를 중단하거나 PSK는 수락하되 0-RTT를 거부한다. 일치하는 ClientHello를 찾지 못하면 0-RTT를 수락하고 expected_arrival_time이 시간 창 안에 있는 동안 ClientHello를 저장한다. 서버는 Bloom 필터처럼 오탐이 발생할 수 있는 데이터 저장소를 구현할 수도 있으며, 이 경우 명백한 재전송에 대해 0-RTT를 반드시 거부해야 하지만 핸드셰이크를 중단해서는 안 된다.¶

서버는 ClientHello에서 검증된 부분만 사용해 저장소 키를 반드시 유도해야 한다. ClientHello에 여러 PSK 식별자가 포함되어 있으면 공격자는 서버가 선호도가 낮은 식별자의 바인더를 검증하지 않을 것이라는 가정하에 해당 식별자의 바인더 값을 다르게 한 여러 ClientHello를 생성할 수 있다 (섹션 4.3.11에서 권고한 방식). 즉, 클라이언트가 PSK A와 B를 전송하지만 서버가 A를 선호하는 경우 공격자는 A의 바인더에 영향을 주지 않고 B의 바인더를 변경할 수 있다. B의 바인더가 저장소 키의 일부라면 이 ClientHello는 중복으로 나타나지 않으므로 수락되며, 재전송 캐시 오염 같은 부작용이 발생할 수 있다. 다만 모든 0-RTT 데이터는 다른 키를 사용하므로 복호화할 수 없다. 검증된 바인더 또는 ClientHello.random을 저장소 키로 사용하면 이 공격은 불가능하다.¶

이 메커니즘은 아직 사용되지 않은 모든 티켓을 저장할 필요가 없으므로 재개 및 0-RTT 비율이 높은 분산 시스템에서 구현하기 더 쉬울 수 있지만, 수신한 ClientHello 메시지를 신뢰성 있게 저장하고 가져오기 어렵기 때문에 재전송 방지 기능이 잠재적으로 더 약할 수 있다. 이러한 시스템 중 다수에서는 수신한 모든 ClientHello를 전역적으로 일관되게 저장하는 것이 비현실적이다. 이 경우 가장 강력한 재전송 방지는 특정 티켓에 대해 하나의 저장소 영역만 권한을 갖게 하고 다른 모든 영역에서는 해당 티켓의 0-RTT를 거부하는 방식이다. 이 방식은 하나의 영역만 0-RTT 데이터를 수락하므로 공격자의 단순 재전송을 방지한다. 더 약한 설계는 각 영역에 별도의 저장소를 구현하면서 모든 영역에서 0-RTT를 허용하는 것이다. 이 방식은 재전송 횟수를 영역당 한 번으로 제한한다. 어느 설계에서도 애플리케이션 메시지 중복은 여전히 가능하다.¶

구현을 새로 시작한 경우 기록 시간 창의 어떤 부분이라도 시작 시점과 겹치는 동안에는 0-RTT를 거부하는 것이 권고된다. 그렇지 않으면 해당 기간에 원래 전송된 재전송을 수락할 위험이 있다.¶

참고: 클라이언트의 시계가 서버 시계보다 훨씬 빠르면 미래의 시간 창 밖에 있는 ClientHello를 수신할 수 있다. 이 경우 처음에는 1-RTT로 수락되어 클라이언트 재시도를 유발하고, 나중에는 0-RTT로 수락될 수 있다. 이는 섹션 8에 설명된 두 번째 공격 유형의 또 다른 변형이다.¶

8.3. 최신성 검사

ClientHello는 클라이언트가 이를 전송한 시간을 나타내므로 ClientHello가 비교적 최근에 전송되었을 가능성을 효율적으로 판단하고, 그러한 ClientHello에 대해서만 0-RTT를 수락하며 그 밖의 경우에는 1-RTT 핸드셰이크로 대체할 수 있다. 이는 섹션 8.2에 설명된 ClientHello 저장 메커니즘에 필요하다. 그렇지 않으면 서버가 무제한의 ClientHello를 저장해야 하기 때문이다. 또한 0-RTT에 사용할 수 없는 ClientHello를 효율적으로 거부할 수 있으므로 자체 포함형 일회용 티켓에도 유용한 최적화이다.¶

이 메커니즘을 구현하려면 서버는 서버가 세션 티켓을 생성한 시간에 클라이언트와 서버 간 예상 왕복 시간을 더한 값을 저장해야 한다. 즉,¶

    adjusted_creation_time = creation_time + estimated_RTT

이 값을 티켓에 인코딩하면 아직 사용되지 않은 각 티켓의 상태를 유지할 필요가 없다. 서버는 클라이언트의 "pre_shared_key" 확장에 있는 "obfuscated_ticket_age" 매개변수에서 티켓의 "ticket_age_add" 값을 빼서 클라이언트가 보는 티켓 수명을 판단할 수 있다. 서버는 ClientHello의 expected_arrival_time을 다음과 같이 판단할 수 있다.¶

  expected_arrival_time = adjusted_creation_time + clients_ticket_age

새 ClientHello를 수신하면 expected_arrival_time을 현재 서버 벽시계 시간과 비교하고, 둘의 차이가 일정량을 초과하면 0-RTT를 거부하지만 1-RTT 핸드셰이크는 완료하도록 허용할 수 있다.¶

expected_arrival_time과 측정된 시간이 일치하지 않게 만드는 잠재적인 오류 원인은 여러 가지가 있다. 클라이언트와 서버 시계 속도의 차이는 최소일 가능성이 높지만, 절대 시간은 크게 어긋날 수 있다. 경과 시간의 정상적인 값이 일치하지 않는 가장 가능성 높은 원인은 네트워크 전파 지연이다. NewSessionTicket과 ClientHello 메시지는 재전송되어 지연될 수 있으며, 이 지연은 TCP에 의해 숨겨질 수 있다. 인터넷상의 클라이언트에서는 시계 오류와 측정 편차를 고려하기 위해 대략 10초 규모의 시간 창이 필요함을 의미한다. 다른 배포 환경에서는 요구사항이 다를 수 있다. 시계 편차 분포는 대칭이 아니므로 최적의 절충안은 허용 가능한 불일치 값의 비대칭 범위를 사용할 수 있다.¶

최신성 검사만으로는 오류 시간 창 안의 재전송을 탐지하지 못하므로 재전송을 방지하기에 충분하지 않다는 점에 유의한다. 이 시간 창에는 대역폭과 시스템 용량에 따라 실제 환경에서 수십억 회의 재전송이 포함될 수 있다. 또한 이 최신성 검사는 ClientHello를 수신할 때만 수행되며 이후의 초기 애플리케이션 데이터 레코드를 수신할 때는 수행되지 않는다. 초기 데이터를 수락한 후 레코드는 더 긴 시간 동안 서버로 계속 스트리밍될 수 있다.¶

9.1. 필수 구현 암호 스위트

달리 명세하는 애플리케이션 프로필 표준이 없는 경우:¶

• TLS 준수 애플리케이션은 TLS_AES_128_GCM_SHA256 [GCM] 암호 스위트를 반드시 구현해야 하며, TLS_AES_256_GCM_SHA384 [GCM] 및 TLS_CHACHA20_POLY1305_SHA256 [RFC8439] 암호 스위트를 구현하는 것이 권고된다 (부록 B.4 참조).¶

• TLS 준수 애플리케이션은 rsa_pkcs1_sha256(인증서용), rsa_pss_rsae_sha256(CertificateVerify 및 인증서용), ecdsa_secp256r1_sha256을 사용하는 디지털 서명을 반드시 지원해야 한다. TLS 준수 애플리케이션은 secp256r1(NIST P-256)을 사용한 키 교환을 반드시 지원해야 하며, X25519 [RFC7748]를 사용한 키 교환을 지원하는 것이 권고된다.¶

9.2. 필수 구현 확장

달리 명세하는 애플리케이션 프로필 표준이 없는 경우, TLS 준수 애플리케이션은 다음 TLS 확장을 반드시 구현해야 한다.¶

• 지원되는 버전 ("supported_versions"; 섹션 4.3.1)¶

• 쿠키 ("cookie"; 섹션 4.3.2)¶

• 서명 알고리즘 ("signature_algorithms"; 섹션 4.3.3)¶

• 인증서 서명 알고리즘 ("signature_algorithms_cert"; 섹션 4.3.3)¶

• 지원되는 그룹 ("supported_groups"; 섹션 4.3.7)¶

• 키 공유 ("key_share"; 섹션 4.3.8)¶

• 서버 이름 표시 ("server_name"; [RFC6066]의 섹션 3)¶

모든 구현은 해당 기능을 제공할 때 이러한 확장을 반드시 전송하고 사용해야 한다.¶

• "supported_versions"는 모든 ClientHello, ServerHello 및 HelloRetryRequest 메시지에 필수이다.¶

• "signature_algorithms"는 인증서 인증에 필수이다.¶

• "supported_groups"는 DHE 또는 ECDHE 키 교환을 사용하는 ClientHello 메시지에 필수이다.¶

• "key_share"는 DHE 또는 ECDHE 키 교환에 필수이다.¶

• "pre_shared_key"는 PSK 키 합의에 필수이다.¶

• "psk_key_exchange_modes"는 PSK 키 합의에 필수이다.¶

ClientHello에 본문에 0x0304가 포함된 "supported_versions" 확장이 있으면 클라이언트가 이 명세를 사용해 협상을 시도하는 것으로 간주한다. 이러한 ClientHello 메시지는 다음 요구사항을 반드시 충족해야 한다.¶

• "pre_shared_key" 확장을 포함하지 않는 경우 "signature_algorithms" 확장과 "supported_groups" 확장을 모두 반드시 포함해야 한다.¶

• "supported_groups" 확장을 포함하는 경우 "key_share" 확장도 반드시 포함해야 하며, 그 반대도 마찬가지이다. 빈 KeyShare.client_shares 목록은 허용된다.¶

이러한 요구사항을 준수하지 않는 ClientHello를 수신한 서버는 "missing_extension" 경고와 함께 핸드셰이크를 반드시 중단해야 한다.¶

또한 모든 구현은 이를 사용할 수 있는 애플리케이션과 함께 "server_name" 확장의 사용을 반드시 지원해야 한다. 서버는 클라이언트가 유효한 "server_name" 확장을 전송하도록 요구할 수 있다. 이 확장을 요구하는 서버는 "server_name" 확장이 없는 ClientHello에 대해 "missing_extension" 경고와 함께 연결을 종료하여 응답하는 것이 권고된다.¶

9.3. 프로토콜 불변 조건

이 섹션에서는 TLS 엔드포인트와 미들박스가 반드시 따라야 하는 불변 조건을 설명한다. 이는 이전 TLS 버전에도 적용된다.¶

TLS는 안전하고 호환성 있게 확장할 수 있도록 설계되었다. 최신 클라이언트나 서버가 최신 피어와 통신할 때는 공통으로 지원하는 매개변수 중 가장 선호하는 것을 협상해야 한다. TLS 핸드셰이크는 다운그레이드 보호를 제공한다. TLS를 종료하지 않고 최신 클라이언트와 최신 서버 사이의 트래픽을 전달하는 미들박스는 핸드셰이크에 영향을 줄 수 없어야 한다 (부록 F.1 참조). 동시에 배포마다 갱신 속도가 다르므로 최신 클라이언트나 서버는 이전 엔드포인트와 상호 운용할 수 있도록 이전 매개변수를 계속 지원할 수 있다.¶

이를 위해 구현은 확장 가능한 필드를 올바르게 반드시 처리해야 한다.¶

• ClientHello를 전송하는 클라이언트는 그 안에서 알린 모든 비GREASE [RFC8701] 매개변수를 반드시 지원해야 한다. 그렇지 않으면 서버가 해당 매개변수 중 하나를 선택하여 상호 운용에 실패할 수 있다.¶

• ClientHello를 수신한 서버는 인식하지 못하는 모든 암호 스위트, 확장 및 기타 매개변수를 올바르게 반드시 무시해야 한다. 그렇지 않으면 최신 클라이언트와 상호 운용하지 못할 수 있다. TLS 1.3에서 CertificateRequest 또는 NewSessionTicket을 수신한 클라이언트도 인식하지 못하는 모든 확장을 반드시 무시해야 한다.¶

• TLS 연결을 종료하는 미들박스는 원래 클라이언트에 대해서는 클라이언트가 수락할 의향이 있는 인증서를 갖는 것을 포함해 준수하는 TLS 서버처럼 반드시 동작해야 하며, 원래 서버에 대해서는 원래 서버의 인증서를 검증하는 것을 포함해 준수하는 TLS 클라이언트처럼도 동작해야 한다. 특히 자신이 이해하는 매개변수만 포함하는 자체 ClientHello를 반드시 생성해야 하며, 엔드포인트의 값을 전달하는 대신 새로운 ServerHello random 값을 반드시 생성해야 한다.¶

  TLS의 프로토콜 요구사항과 보안 분석은 두 연결에 각각 별도로만 적용된다는 점에 유의한다. TLS 종료 장치를 안전하게 배포하려면 이 문서의 범위를 벗어나는 추가 보안 고려사항이 필요하다.¶

• 이해하지 못하는 ClientHello 매개변수를 전달하는 미들박스는 해당 ClientHello 뒤의 어떤 메시지도 처리해서는 안 된다. 이후의 모든 트래픽을 수정 없이 반드시 전달해야 한다. 그렇지 않으면 최신 클라이언트 및 서버와 상호 운용하지 못할 수 있다.¶

  전달된 ClientHello에는 미들박스가 지원하지 않는 기능에 대한 표시가 포함될 수 있으므로 응답에는 미들박스가 인식하지 못하는 향후 TLS 추가 사항이 포함될 수 있다. 이러한 추가 사항은 ClientHello 뒤의 모든 메시지를 임의로 변경할 수 있다. 특히 ServerHello에서 전송되는 값, ServerHello 형식 및 TLSCiphertext 형식이 변경될 수 있다.¶

TLS 1.3의 설계는 널리 배포된 비준수 TLS 미들박스의 제약을 받았지만 (부록 E.4 참조), 불변 조건을 완화하지는 않는다. 이러한 미들박스는 계속 비준수 상태이다.¶

11.1. 이 RFC의 변경 사항

IANA는 IANA 레지스트리의 [RFC8446]에 대한 모든 참조를 이 문서에 대한 참조로 갱신했다.¶

IANA는 TLS SignatureScheme 및 PskKeyExchangeMode 레지스트리의 "Recommended" 열 절차를 [RFC9847]과 일치하도록 갱신했다.¶

IANA는 TLS ExtensionType Values 레지스트리의 "extended_master_secret" 값을 "extended_main_secret"으로 이름을 변경했다.¶

IANA는 섹션 6에 제시된 값을 사용하여 TLS Alerts 레지스트리에 "general_error" 경고 값을 생성했다.¶

IANA는 TLS ExtensionType Values 레지스트리의 status_request 및 supported_groups 항목에 이 문서에 대한 참조를 추가했다.¶

IANA는 cached_info에 대한 "TLS 1.3" 열의 TLS ExtensionType 값을 "CH, EE"로 갱신했다.¶

12.1. 규범적 참고문헌

[GCM]

Dworkin, M., "블록 암호 동작 모드 권고안: 갈루아/카운터 모드(GCM) 및 GMAC", NIST SP 800-38D, DOI 10.6028/NIST.SP.800-38D, 2007년 11월, <https://doi.org/10.6028/NIST.SP.800-38D>.

[KEYAGREEMENT]

Barker, E., Chen, L., Roginsky, A., Vassilev, A. 및 R. Davis, "이산 로그 암호화를 사용한 쌍별 키 설정 방식 권고안", 미국 국립표준기술연구소, DOI 10.6028/nist.sp.800-56ar3, 2018년 4월, <https://doi.org/10.6028/nist.sp.800-56ar3>.

[RFC2104]

Krawczyk, H., Bellare, M. 및 R. Canetti, "HMAC: 메시지 인증을 위한 키 기반 해싱", RFC 2104, DOI 10.17487/RFC2104, 1997년 2월, <https://www.rfc-editor.org/info/rfc2104>.

[RFC2119]

Bradner, S., "요구사항 수준을 나타내기 위해 RFC에서 사용하는 핵심 단어", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997년 3월, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3279]

Bassham, L., Polk, W. 및 R. Housley, "인터넷 X.509 공개 키 인프라 인증서 및 인증서 폐기 목록(CRL) 프로필의 알고리즘과 식별자", RFC 3279, DOI 10.17487/RFC3279, 2002년 5월, <https://www.rfc-editor.org/info/rfc3279>.

[RFC5116]

McGrew, D., "인증된 암호화를 위한 인터페이스와 알고리즘", RFC 5116, DOI 10.17487/RFC5116, 2008년 1월, <https://www.rfc-editor.org/info/rfc5116>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. 및 W. Polk, "인터넷 X.509 공개 키 인프라 인증서 및 인증서 폐기 목록(CRL) 프로필", RFC 5280, DOI 10.17487/RFC5280, 2008년 5월, <https://www.rfc-editor.org/info/rfc5280>.

[RFC5705]

Rescorla, E., "전송 계층 보안(TLS)의 키 자료 익스포터", RFC 5705, DOI 10.17487/RFC5705, 2010년 3월, <https://www.rfc-editor.org/info/rfc5705>.

[RFC5756]

Turner, S., Brown, D., Yiu, K., Housley, R. 및 T. Polk, "RSAES-OAEP 및 RSASSA-PSS 알고리즘 매개변수 갱신", RFC 5756, DOI 10.17487/RFC5756, 2010년 1월, <https://www.rfc-editor.org/info/rfc5756>.

[RFC5869]

Krawczyk, H. 및 P. Eronen, "HMAC 기반 추출 및 확장 키 유도 함수 (HKDF)", RFC 5869, DOI 10.17487/RFC5869, 2010년 5월, <https://www.rfc-editor.org/info/rfc5869>.

[RFC6066]

Eastlake 3rd, D., "전송 계층 보안(TLS) 확장: 확장 정의", RFC 6066, DOI 10.17487/RFC6066, 2011년 1월, <https://www.rfc-editor.org/info/rfc6066>.

[RFC6655]

McGrew, D. 및 D. Bailey, "전송 계층 보안(TLS)을 위한 AES-CCM 암호 스위트", RFC 6655, DOI 10.17487/RFC6655, 2012년 7월, <https://www.rfc-editor.org/info/rfc6655>.

[RFC6960]

Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S. 및 C. Adams, "X.509 인터넷 공개 키 인프라 온라인 인증서 상태 프로토콜 - OCSP", RFC 6960, DOI 10.17487/RFC6960, 2013년 6월, <https://www.rfc-editor.org/info/rfc6960>.

[RFC6961]

Pettersen, Y., "전송 계층 보안(TLS) 다중 인증서 상태 요청 확장", RFC 6961, DOI 10.17487/RFC6961, 2013년 6월, <https://www.rfc-editor.org/info/rfc6961>.

[RFC6962]

Laurie, B., Langley, A. 및 E. Kasper, "인증서 투명성", RFC 6962, DOI 10.17487/RFC6962, 2013년 6월, <https://www.rfc-editor.org/info/rfc6962>.

[RFC6979]

Pornin, T., "디지털 서명 알고리즘(DSA) 및 타원 곡선 디지털 서명 알고리즘(ECDSA)의 결정적 사용", RFC 6979, DOI 10.17487/RFC6979, 2013년 8월, <https://www.rfc-editor.org/info/rfc6979>.

[RFC7301]

Friedl, S., Popov, A., Langley, A. 및 E. Stephan, "전송 계층 보안(TLS) 애플리케이션 계층 프로토콜 협상 확장", RFC 7301, DOI 10.17487/RFC7301, 2014년 7월, <https://www.rfc-editor.org/info/rfc7301>.

[RFC7507]

Moeller, B. 및 A. Langley, "프로토콜 다운그레이드 공격 방지를 위한 TLS 대체 신호 암호 스위트 값(SCSV)", RFC 7507, DOI 10.17487/RFC7507, 2015년 4월, <https://www.rfc-editor.org/info/rfc7507>.

[RFC7627]

Bhargavan, K., 편집자, Delignat-Lavaud, A., Pironti, A., Langley, A. 및 M. Ray, "전송 계층 보안(TLS) 세션 해시 및 확장 주 비밀값 확장", RFC 7627, DOI 10.17487/RFC7627, 2015년 9월, <https://www.rfc-editor.org/info/rfc7627>.

[RFC7748]

Langley, A., Hamburg, M. 및 S. Turner, "보안을 위한 타원 곡선", RFC 7748, DOI 10.17487/RFC7748, 2016년 1월, <https://www.rfc-editor.org/info/rfc7748>.

[RFC7919]

Gillmor, D., "전송 계층 보안(TLS)을 위한 협상된 유한체 임시 디피-헬먼 매개변수", RFC 7919, DOI 10.17487/RFC7919, 2016년 8월, <https://www.rfc-editor.org/info/rfc7919>.

[RFC8017]

Moriarty, K., 편집자, Kaliski, B., Jonsson, J. 및 A. Rusch, "PKCS #1: RSA 암호화 명세 버전 2.2", RFC 8017, DOI 10.17487/RFC8017, 2016년 11월, <https://www.rfc-editor.org/info/rfc8017>.

[RFC8032]

Josefsson, S. 및 I. Liusvaara, "에드워즈 곡선 디지털 서명 알고리즘 (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, 2017년 1월, <https://www.rfc-editor.org/info/rfc8032>.

[RFC8126]

Cotton, M., Leiba, B. 및 T. Narten, "RFC의 IANA 고려사항 섹션 작성 지침", BCP 26, RFC 8126, DOI 10.17487/RFC8126, 2017년 6월, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174]

Leiba, B., "RFC 2119 핵심 단어의 대문자와 소문자 모호성", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2017년 5월, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8439]

Nir, Y. 및 A. Langley, "IETF 프로토콜을 위한 ChaCha20 및 Poly1305", RFC 8439, DOI 10.17487/RFC8439, 2018년 6월, <https://www.rfc-editor.org/info/rfc8439>.

[RFC8701]

Benjamin, D., "TLS 확장성에 무작위 확장을 생성하고 확장성을 유지하는 기법(GREASE) 적용", RFC 8701, DOI 10.17487/RFC8701, 2020년 1월, <https://www.rfc-editor.org/info/rfc8701>.

[RFC8996]

Moriarty, K. 및 S. Farrell, "TLS 1.0 및 TLS 1.1 사용 중단", BCP 195, RFC 8996, DOI 10.17487/RFC8996, 2021년 3월, <https://www.rfc-editor.org/info/rfc8996>.

[SHS]

"안전한 해시 표준", 미국 국립표준기술연구소, DOI 10.6028/nist.fips.180-4, 2015년, <https://doi.org/10.6028/nist.fips.180-4>.

[X690]

ITU-T, "정보 기술 - ASN.1 인코딩 규칙: 기본 인코딩 규칙(BER), 정규 인코딩 규칙(CER) 및 식별 인코딩 규칙(DER)의 명세", ITU-T 권고안 X.690, 2021년 2월, <https://www.itu.int/rec/T-REC-X.690-202102-I/en>.

12.2. 정보 제공용 참고문헌

[AEAD-LIMITS]

Luykx, A. 및 K. Paterson, "TLS에서 인증된 암호화 사용 제한", 2017년 8월, <https://eprint.iacr.org/2024/051>.

[BBFGKZ16]

Bhargavan, K., Brzuska, C., Fournet, C., Green, M., Kohlweiss, M. 및 S. Zanella-Beguelin, "키 교환 프로토콜의 다운그레이드 복원력", IEEE, 2016 IEEE 보안 및 개인정보 보호 심포지엄(SP) 506-525쪽, DOI 10.1109/sp.2016.37, 2016년 5월, <https://doi.org/10.1109/sp.2016.37>.

[BBK17]

Bhargavan, K., Blanchet, B. 및 N. Kobeissi, "TLS 1.3 표준 후보의 검증된 모델 및 참조 구현", IEEE, 2017 IEEE 보안 및 개인정보 보호 심포지엄(SP) 483-502쪽, DOI 10.1109/sp.2017.26, 2017년 5월, <https://doi.org/10.1109/sp.2017.26>.

[BDFKPPRSZZ16]

Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Kohlweiss, M., Pan, J., Protzenko, J., Rastogi, A., Swamy, N., Zanella-Beguelin, S. 및 J. Zinzindohoue, "TLS 1.3 레코드 계층 구현 및 증명", 2017년 IEEE 보안 및 개인정보 보호 심포지엄(산호세) 회의록, 2016년 12월, <https://eprint.iacr.org/2016/1178>.

[Ben17a]

Benjamin, D., "IETF 100에서 TLS WG에 발표한 자료", IETF 100 회의록, 2017년 11월, <https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-tls13/>.

[Ben17b]

Benjamin, D., "Chrome의 추가 TLS 1.3 결과", TLS 메일링 목록에 보낸 메시지, 2017년 12월 18일, <https://mailarchive.ietf.org/arch/msg/tls/i9blmvG2BEPf1s1OJkenHknRw9c/>.

[Blei98]

Bleichenbacher, D., "RSA 암호화 표준 PKCS #1 기반 프로토콜에 대한 선택 암호문 공격", CRYPTO '98 회의록, 1998년, <https://link.springer.com/chapter/10.1007/bfb0055716>.

[BMMRT15]

Badertscher, C., Matt, C., Maurer, U., Rogaway, P. 및 B. Tackmann, "증강된 보안 채널과 TLS 1.3 레코드 계층의 목표", ProvSec 2015, 2015년 9월, <https://eprint.iacr.org/2015/394>.

[BT16]

Bellare, M. 및 B. Tackmann, "인증된 암호화의 다중 사용자 보안: TLS 1.3의 AES-GCM", CRYPTO 2016 회의록, 2016년 7월, <https://eprint.iacr.org/2016/564>.

[CCG16]

Cohn-Gordon, K., Cremers, C. 및 L. Garratt, "침해 후 보안에 관하여", IEEE, 2016 IEEE 제29회 컴퓨터 보안 기반 심포지엄(CSF) 164-178쪽, DOI 10.1109/csf.2016.19, 2016년 6월, <https://doi.org/10.1109/csf.2016.19>.

[CHECKOWAY]

Checkoway, S., Maskiewicz, J., Garman, C., Fried, J., Cohney, S., Green, M., Heninger, N., Weinmann, R., Rescorla, E. 및 H. Shacham, "Juniper Dual EC 사건의 체계적 분석", ACM, 2016 ACM SIGSAC 컴퓨터 및 통신 보안 콘퍼런스 회의록 468-479쪽, DOI 10.1145/2976749.2978395, 2016년 10월, <https://doi.org/10.1145/2976749.2978395>.

[CHHSV17]

Cremers, C., Horvat, M., Hoyland, J., van der Merwe, T. 및 S. Scott, "곤란한 핸드셰이크: 리비전 18의 핸드셰이크 후 모드에서 클라이언트 인증에 대한 클라이언트/서버 관점이 불일치할 가능성", TLS 메일링 목록에 보낸 메시지, 2017년 2월 10일, <https://mailarchive.ietf.org/arch/msg/tls/crdSCgiW-94z2joulYJtuA52E9E/>.

[CHSV16]

Cremers, C., Horvat, M., Scott, S. 및 T. van der Merwe, "TLS 1.3의 자동 분석 및 검증: 0-RTT, 재개 및 지연된 인증", IEEE, 2016 IEEE 보안 및 개인정보 보호 심포지엄(SP) 470-485쪽, DOI 10.1109/sp.2016.35, 2016년 5월, <https://doi.org/10.1109/sp.2016.35>.

[CK01]

Canetti, R. 및 H. Krawczyk, "키 교환 프로토콜과 보안 채널 구축에서의 사용 분석", Springer Berlin Heidelberg, 컴퓨터 과학 강의 노트 453-474쪽, DOI 10.1007/3-540-44987-6_28, ISBN ["9783540420705", "9783540449874"], 2001년, <https://doi.org/10.1007/3-540-44987-6_28>.

[CLINIC]

Miller, B., Huang, L., Joseph, A. 및 J. Tygar, "당신이 병원에 간 이유를 알고 있다: HTTPS 트래픽 분석의 위험과 실현", Springer International Publishing, 컴퓨터 과학 강의 노트 143-163쪽, DOI 10.1007/978-3-319-08506-7_8, ISBN ["9783319085050", "9783319085067"], 2014년, <https://doi.org/10.1007/978-3-319-08506-7_8>.

[DFGS15]

Dowling, B., Fischlin, M., Guenther, F. 및 D. Stebila, "TLS 1.3 draft-10 전체 및 사전 공유 키 핸드셰이크 프로토콜의 암호학적 분석", ACM CCS 2015 회의록, 2015년 10월, <https://eprint.iacr.org/2015/914>.

[DFGS16]

Dowling, B., Fischlin, M., Guenther, F. 및 D. Stebila, "TLS 1.3 draft-10 전체 및 사전 공유 키 핸드셰이크 프로토콜의 암호학적 분석", TRON 2016, 2016년 2월, <https://eprint.iacr.org/2016/081>.

[DH76]

Diffie, W. 및 M. Hellman, "암호학의 새로운 방향", 전기전자공학자협회(IEEE), IEEE 정보 이론 회보 22권 6호, 644-654쪽, DOI 10.1109/tit.1976.1055638, 1976년 11월, <https://doi.org/10.1109/tit.1976.1055638>.

[DOW92]

Diffie, W., Van Oorschot, P. 및 M. Wiener, "인증 및 인증된 키 교환", Springer Science and Business Media LLC, 설계, 코드 및 암호학 2권 2호, 107-125쪽, DOI 10.1007/bf00124891, 1992년 6월, <https://doi.org/10.1007/bf00124891>.

[DSA-1571-1]

Weimer, F., "[보안] [DSA 1571-1] 새로운 openssl 패키지가 예측 가능한 난수 생성기를 수정함", debian-security-announce 메일링 목록에 보낸 메시지, 2008년 5월, <https://www.debian.org/security/2008/dsa-1571>.

[DSS]

"디지털 서명 표준(DSS)", 미국 국립표준기술연구소, DOI 10.6028/nist.fips.186-5, 2023년 2월, <https://doi.org/10.6028/nist.fips.186-5>.

[ECDP]

Chen, L., Moody, D., Regenscheid, A., Robinson, A. 및 K. Randall, "이산 로그 기반 암호화 권고안: 타원 곡선 도메인 매개변수", 미국 국립표준기술연구소, DOI 10.6028/nist.sp.800-186, 2023년 2월, <https://doi.org/10.6028/nist.sp.800-186>.

[FETCH]

WHATWG, "Fetch", WHATWG 현행 표준, <https://fetch.spec.whatwg.org/>. 커밋 스냅샷: https://fetch.spec.whatwg.org/commit-snapshots/4775fcb48042c8411df497c0b7cf167b4240004f/

[FG17]

Fischlin, M. 및 F. Guenther, "제로 라운드 트립 시간에 대한 재전송 공격: TLS 1.3 핸드셰이크 후보의 사례", Euro S&P 2017 회의록, 2017년 4월, <https://eprint.iacr.org/2017/082>.

[FGSW16]

Fischlin, M., Guenther, F., Schmidt, B. 및 B. Warinschi, "키 교환의 키 확인: 형식적 처리와 TLS 1.3에 대한 함의", 2016년 IEEE 보안 및 개인정보 보호 심포지엄(오클랜드) 회의록, DOI 10.1109/SP.2016.34, 2016년, <http://ieeexplore.ieee.org/document/7546517/>.

[FW15]

Weimer, F., "TLS 완전 순방향 비밀성으로 RSA 키 인수분해하기", Red Hat 블로그, 2015년 9월 2일, <https://www.redhat.com/en/blog/factoring-rsa-keys-tls-perfect-forward-secrecy>.

[HCJC16]

Husák, M., Čermák, M., Jirsík, T. 및 P. Čeleda, "수동 SSL/TLS 지문 분석을 사용한 HTTPS 트래픽 분석 및 클라이언트 식별", Springer Science and Business Media LLC, EURASIP 정보 보안 저널 2016권 1호, DOI 10.1186/s13635-016-0030-7, 2016년 2월, <https://doi.org/10.1186/s13635-016-0030-7>.

[HGFS15]

Hlauschek, C., Gruber, M., Fankhauser, F. 및 C. Schanes, "판도라의 상자를 열어젖히기: TLS에 대한 KCI 공격", USENIX 공격 기술 워크숍 회의록, 2015년, <https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek>.

[JSS15]

Jager, T., Schwenk, J. 및 J. Somorovsky, "PKCS#1 v1.5 암호화의 약점에 대한 TLS 1.3 및 QUIC의 보안", ACM, 제22회 ACM SIGSAC 컴퓨터 및 통신 보안 콘퍼런스 회의록 1185-1196쪽, DOI 10.1145/2810103.2813657, 2015년 10월, <https://doi.org/10.1145/2810103.2813657>.

[Kraw10]

Krawczyk, H., "암호학적 추출 및 키 유도: HKDF 방식", CRYPTO 2010 회의록, 2010년, <https://eprint.iacr.org/2010/264>.

[Kraw16]

Krawczyk, H., "키 교환을 위한 단방향-상호 인증 컴파일러(TLS 1.3의 클라이언트 인증에 대한 적용 포함)", ACM CCS 2016 회의록, 2016년 10월, <https://eprint.iacr.org/2016/711>.

[KW16]

Krawczyk, H. 및 H. Wee, "OPTLS 프로토콜과 TLS 1.3", Euro S&P 2016 회의록, 2016년 3월, <https://eprint.iacr.org/2015/978>.

[LXZFH16]

Li, X., Xu, J., Zhang, Z., Feng, D. 및 H. Hu, "TLS 1.3 후보의 다중 핸드셰이크 보안", IEEE, 2016 IEEE 보안 및 개인정보 보호 심포지엄(SP) 486-505쪽, DOI 10.1109/sp.2016.36, 2016년 5월, <https://doi.org/10.1109/sp.2016.36>.

[Mac17]

MacCarthaigh, C., "TLS1.3 0-RTT 보안 검토", 2017년 5월, <https://github.com/tlswg/tls13-spec/issues/1001>.

[MM24]

Moustafa, M., Sethi, M. 및 T. Aura, "TLS에서 원시 공개 키를 신원에 잘못 바인딩하기", arxiv:2411.09770, 2025년 9월 29일, <https://arxiv.org/pdf/2411.09770>.

[PS18]

Patton, C. 및 T. Shrimpton, "부분적으로 명세된 채널: 생략 없는 TLS 1.3 레코드 계층", 2018년, <https://eprint.iacr.org/2018/634>.

[PSK-FINISHED]

Cremers, C., Horvat, M., van der Merwe, T. 및 S. Scott, "리비전 10: PSK 중 클라이언트 인증이 허용될 경우 가능한 공격", TLS 메일링 목록에 보낸 메시지, 2015년 10월 31일, <https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/>.

[REKEY]

Abdalla, M. 및 M. Bellare, "키 수명 연장: 키 재설정 기법 보안의 비교 분석", Springer Berlin Heidelberg, 컴퓨터 과학 강의 노트 546-559쪽, DOI 10.1007/3-540-44448-3_42, ISBN ["9783540414049", "9783540444480"], 2000년, <https://doi.org/10.1007/3-540-44448-3_42>.

[Res17a]

Rescorla, E., "Firefox TLS 1.3 미들박스 실험의 예비 데이터", TLS 메일링 목록에 보낸 메시지, 2017년 12월 5일, <https://mailarchive.ietf.org/arch/msg/tls/RBp0X-OWNuWXugFJRV7c_hIU0dI/>.

[Res17b]

Rescorla, E., "추가 호환성 측정 결과", TLS 메일링 목록에 보낸 메시지, 2017년 12월 22일, <https://mailarchive.ietf.org/arch/msg/tls/6pGGT-wm5vSkacMFPEPvFMEnj-M/>.

[RFC2246]

Dierks, T. 및 C. Allen, "TLS 프로토콜 버전 1.0", RFC 2246, DOI 10.17487/RFC2246, 1999년 1월, <https://www.rfc-editor.org/info/rfc2246>.

[RFC3552]

Rescorla, E. 및 B. Korver, "RFC의 보안 고려사항 텍스트 작성 지침", BCP 72, RFC 3552, DOI 10.17487/RFC3552, 2003년 7월, <https://www.rfc-editor.org/info/rfc3552>.

[RFC4086]

Eastlake 3rd, D., Schiller, J. 및 S. Crocker, "보안을 위한 무작위성 요구사항", BCP 106, RFC 4086, DOI 10.17487/RFC4086, 2005년 6월, <https://www.rfc-editor.org/info/rfc4086>.

[RFC4346]

Dierks, T. 및 E. Rescorla, "전송 계층 보안(TLS) 프로토콜 버전 1.1", RFC 4346, DOI 10.17487/RFC4346, 2006년 4월, <https://www.rfc-editor.org/info/rfc4346>.

[RFC4366]

Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. 및 T. Wright, "전송 계층 보안(TLS) 확장", RFC 4366, DOI 10.17487/RFC4366, 2006년 4월, <https://www.rfc-editor.org/info/rfc4366>.

[RFC4492]

Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C. 및 B. Moeller, "전송 계층 보안(TLS)을 위한 타원 곡선 암호화(ECC) 암호 스위트", RFC 4492, DOI 10.17487/RFC4492, 2006년 5월, <https://www.rfc-editor.org/info/rfc4492>.

[RFC5077]

Salowey, J., Zhou, H., Eronen, P. 및 H. Tschofenig, "서버 측 상태 없는 전송 계층 보안(TLS) 세션 재개", RFC 5077, DOI 10.17487/RFC5077, 2008년 1월, <https://www.rfc-editor.org/info/rfc5077>.

[RFC5246]

Dierks, T. 및 E. Rescorla, "전송 계층 보안(TLS) 프로토콜 버전 1.2", RFC 5246, DOI 10.17487/RFC5246, 2008년 8월, <https://www.rfc-editor.org/info/rfc5246>.

[RFC5763]

Fischl, J., Tschofenig, H. 및 E. Rescorla, "데이터그램 전송 계층 보안(DTLS)을 사용하여 안전한 실시간 전송 프로토콜(SRTP) 보안 콘텍스트를 설정하기 위한 프레임워크", RFC 5763, DOI 10.17487/RFC5763, 2010년 5월, <https://www.rfc-editor.org/info/rfc5763>.

[RFC5764]

McGrew, D. 및 E. Rescorla, "안전한 실시간 전송 프로토콜(SRTP)의 키를 설정하기 위한 데이터그램 전송 계층 보안(DTLS) 확장", RFC 5764, DOI 10.17487/RFC5764, 2010년 5월, <https://www.rfc-editor.org/info/rfc5764>.

[RFC5929]

Altman, J., Williams, N. 및 L. Zhu, "TLS의 채널 바인딩", RFC 5929, DOI 10.17487/RFC5929, 2010년 7월, <https://www.rfc-editor.org/info/rfc5929>.

[RFC6091]

Mavrogiannopoulos, N. 및 D. Gillmor, "전송 계층 보안(TLS) 인증에 OpenPGP 키 사용", RFC 6091, DOI 10.17487/RFC6091, 2011년 2월, <https://www.rfc-editor.org/info/rfc6091>.

[RFC6101]

Freier, A., Karlton, P. 및 P. Kocher, "보안 소켓 계층 (SSL) 프로토콜 버전 3.0", RFC 6101, DOI 10.17487/RFC6101, 2011년 8월, <https://www.rfc-editor.org/info/rfc6101>.

[RFC6176]

Turner, S. 및 T. Polk, "보안 소켓 계층(SSL) 버전 2.0 금지", RFC 6176, DOI 10.17487/RFC6176, 2011년 3월, <https://www.rfc-editor.org/info/rfc6176>.

[RFC6520]

Seggelmann, R., Tuexen, M. 및 M. Williams, "전송 계층 보안(TLS) 및 데이터그램 전송 계층 보안(DTLS) 하트비트 확장", RFC 6520, DOI 10.17487/RFC6520, 2012년 2월, <https://www.rfc-editor.org/info/rfc6520>.

[RFC7250]

Wouters, P., 편집자, Tschofenig, H., 편집자, Gilmore, J., Weiler, S. 및 T. Kivinen, "전송 계층 보안(TLS) 및 데이터그램 전송 계층 보안(DTLS)에서 원시 공개 키 사용", RFC 7250, DOI 10.17487/RFC7250, 2014년 6월, <https://www.rfc-editor.org/info/rfc7250>.

[RFC7465]

Popov, A., "RC4 암호 스위트 금지", RFC 7465, DOI 10.17487/RFC7465, 2015년 2월, <https://www.rfc-editor.org/info/rfc7465>.

[RFC7568]

Barnes, R., Thomson, M., Pironti, A. 및 A. Langley, "보안 소켓 계층 버전 3.0 사용 중단", RFC 7568, DOI 10.17487/RFC7568, 2015년 6월, <https://www.rfc-editor.org/info/rfc7568>.

[RFC7624]

Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C. 및 D. Borkmann, "광범위한 감시에 직면한 기밀성: 위협 모델과 문제 설명", RFC 7624, DOI 10.17487/RFC7624, 2015년 8월, <https://www.rfc-editor.org/info/rfc7624>.

[RFC7685]

Langley, A., "전송 계층 보안(TLS) ClientHello 패딩 확장", RFC 7685, DOI 10.17487/RFC7685, 2015년 10월, <https://www.rfc-editor.org/info/rfc7685>.

[RFC7924]

Santesson, S. 및 H. Tschofenig, "전송 계층 보안(TLS) 캐시 정보 확장", RFC 7924, DOI 10.17487/RFC7924, 2016년 7월, <https://www.rfc-editor.org/info/rfc7924>.

[RFC8305]

Schinazi, D. 및 T. Pauly, "Happy Eyeballs 버전 2: 동시성을 사용한 더 나은 연결성", RFC 8305, DOI 10.17487/RFC8305, 2017년 12월, <https://www.rfc-editor.org/info/rfc8305>.

[RFC8422]

Nir, Y., Josefsson, S. 및 M. Pegourie-Gonnard, "전송 계층 보안(TLS) 버전 1.2 이하를 위한 타원 곡선 암호화(ECC) 암호 스위트", RFC 8422, DOI 10.17487/RFC8422, 2018년 8월, <https://www.rfc-editor.org/info/rfc8422>.

[RFC8446]

Rescorla, E., "전송 계층 보안(TLS) 프로토콜 버전 1.3", RFC 8446, DOI 10.17487/RFC8446, 2018년 8월, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8447]

Salowey, J. 및 S. Turner, "TLS 및 DTLS의 IANA 레지스트리 갱신", RFC 8447, DOI 10.17487/RFC8447, 2018년 8월, <https://www.rfc-editor.org/info/rfc8447>.

[RFC8448]

Thomson, M., "TLS 1.3의 예시 핸드셰이크 추적", RFC 8448, DOI 10.17487/RFC8448, 2019년 1월, <https://www.rfc-editor.org/info/rfc8448>.

[RFC8449]

Thomson, M., "TLS의 레코드 크기 제한 확장", RFC 8449, DOI 10.17487/RFC8449, 2018년 8월, <https://www.rfc-editor.org/info/rfc8449>.

[RFC8470]

Thomson, M., Nottingham, M. 및 W. Tarreau, "HTTP에서 초기 데이터 사용", RFC 8470, DOI 10.17487/RFC8470, 2018년 9월, <https://www.rfc-editor.org/info/rfc8470>.

[RFC8773]

Housley, R., "외부 사전 공유 키와 인증서 기반 인증을 함께 사용하기 위한 TLS 1.3 확장", RFC 8773, DOI 10.17487/RFC8773, 2020년 3월, <https://www.rfc-editor.org/info/rfc8773>.

[RFC8844]

Thomson, M. 및 E. Rescorla, "세션 기술 프로토콜(SDP)과 함께 TLS를 사용할 때의 알 수 없는 키 공유 공격", RFC 8844, DOI 10.17487/RFC8844, 2021년 1월, <https://www.rfc-editor.org/info/rfc8844>.

[RFC8870]

Jennings, C., Mattsson, J., McGrew, D., Wing, D. 및 F. Andreasen, "DTLS 및 안전한 RTP를 위한 암호화된 키 전송", RFC 8870, DOI 10.17487/RFC8870, 2021년 1월, <https://www.rfc-editor.org/info/rfc8870>.

[RFC8879]

Ghedini, A. 및 V. Vasiliev, "TLS 인증서 압축", RFC 8879, DOI 10.17487/RFC8879, 2020년 12월, <https://www.rfc-editor.org/info/rfc8879>.

[RFC8937]

Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N. 및 C. Wood, "보안 프로토콜의 무작위성 개선", RFC 8937, DOI 10.17487/RFC8937, 2020년 10월, <https://www.rfc-editor.org/info/rfc8937>.

[RFC9001]

Thomson, M., 편집자 및 S. Turner, 편집자, "TLS를 사용한 QUIC 보안", RFC 9001, DOI 10.17487/RFC9001, 2021년 5월, <https://www.rfc-editor.org/info/rfc9001>.

[RFC9112]

Fielding, R., 편집자, Nottingham, M., 편집자 및 J. Reschke, 편집자, "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, 2022년 6월, <https://www.rfc-editor.org/info/rfc9112>.

[RFC9147]

Rescorla, E., Tschofenig, H. 및 N. Modadugu, "데이터그램 전송 계층 보안(DTLS) 프로토콜 버전 1.3", RFC 9147, DOI 10.17487/RFC9147, 2022년 4월, <https://www.rfc-editor.org/info/rfc9147>.

[RFC9149]

Pauly, T., Schinazi, D. 및 C.A. Wood, "TLS 티켓 요청", RFC 9149, DOI 10.17487/RFC9149, 2022년 4월, <https://www.rfc-editor.org/info/rfc9149>.

[RFC9162]

Laurie, B., Messeri, E. 및 R. Stradling, "인증서 투명성 버전 2.0", RFC 9162, DOI 10.17487/RFC9162, 2021년 12월, <https://www.rfc-editor.org/info/rfc9162>.

[RFC9257]

Housley, R., Hoyland, J., Sethi, M. 및 C. A. Wood, "TLS에서 외부 사전 공유 키(PSK) 사용 지침", RFC 9257, DOI 10.17487/RFC9257, 2022년 7월, <https://www.rfc-editor.org/info/rfc9257>.

[RFC9258]

Benjamin, D. 및 C. A. Wood, "TLS 1.3을 위한 외부 사전 공유 키(PSK) 가져오기", RFC 9258, DOI 10.17487/RFC9258, 2022년 7월, <https://www.rfc-editor.org/info/rfc9258>.

[RFC9261]

Sullivan, N., "TLS의 내보낸 인증자", RFC 9261, DOI 10.17487/RFC9261, 2022년 7월, <https://www.rfc-editor.org/info/rfc9261>.

[RFC9345]

Barnes, R., Iyengar, S., Sullivan, N. 및 E. Rescorla, "TLS 및 DTLS를 위한 위임된 자격 증명", RFC 9345, DOI 10.17487/RFC9345, 2023년 7월, <https://www.rfc-editor.org/info/rfc9345>.

[RFC9525]

Saint-Andre, P. 및 R. Salz, "TLS의 서비스 신원", RFC 9525, DOI 10.17487/RFC9525, 2023년 11월, <https://www.rfc-editor.org/info/rfc9525>.

[RFC9847]

Salowey, J. 및 S. Turner, "TLS 및 DTLS의 IANA 레지스트리 갱신", RFC 9847, DOI 10.17487/RFC9847, 2025년 12월, <https://www.rfc-editor.org/info/rfc9847>.

[RFC9849]

Rescorla, E., Oku, K., Sullivan, N. 및 C. A. Wood, "TLS 암호화된 클라이언트 헬로", RFC 9849, DOI 10.17487/RFC9849, 2026년 3월, <https://www.rfc-editor.org/info/rfc9849>.

[RFC9963]

Benjamin, D. 및 A. Popov, "TLS 1.3을 위한 레거시 RSASSA-PKCS1-v1_5 코드 포인트", RFC 9963, DOI 10.17487/RFC9963, 2026년 4월, <https://www.rfc-editor.org/info/rfc9963>.

[RSA]

Rivest, R., Shamir, A. 및 L. Adleman, "디지털 서명과 공개 키 암호 시스템을 얻는 방법", 컴퓨팅 기계 협회(ACM), Communications of the ACM 21권 2호, 120-126쪽, DOI 10.1145/359340.359342, 1978년 2월, <https://doi.org/10.1145/359340.359342>.

[Selfie]

Drucker, N. 및 S. Gueron, "Selfie: PSK를 사용하는 TLS 1.3에 대한 고찰", 2019년, <https://eprint.iacr.org/2019/347>.

[SIGMA]

Krawczyk, H., "SIGMA: 인증된 디피-헬먼에 대한 '서명 및 MAC' 접근 방식과 IKE 프로토콜에서의 사용", Springer Berlin Heidelberg, 컴퓨터 과학 강의 노트 400-425쪽, DOI 10.1007/978-3-540-45146-4_24, ISBN ["9783540406747", "9783540451464"], 2003년, <https://doi.org/10.1007/978-3-540-45146-4_24>.

[SLOTH]

Bhargavan, K. 및 G. Leurent, "트랜스크립트 충돌 공격: TLS, IKE 및 SSH의 인증 깨뜨리기", 인터넷 소사이어티, 2016 네트워크 및 분산 시스템 보안 심포지엄 회의록, DOI 10.14722/ndss.2016.23418, 2016년, <https://doi.org/10.14722/ndss.2016.23418>.

[SSL2]

Hickman, K. E., "SSL 프로토콜", 1995년 2월 9일, <https://datatracker.ietf.org/doc/html/draft-hickman-netscape-ssl-00>.

[TIMING]

Boneh, D. 및 D. Brumley, "원격 타이밍 공격은 실용적이다", 제12회 USENIX 보안 심포지엄(USENIX Security 03), 2003년, <https://www.usenix.org/conference/12th-usenix-security-symposium/remote-timing-attacks-are-practical>.

[X501]

ITU-T, "정보 기술 - 개방형 시스템 상호 연결 - 디렉터리: 모델", ITU-T 권고안 X.501, ISO/IEC 9594-2:2020, 2019년 10월, <https://www.itu.int/rec/T-REC-X.501-201910-I/en>.

A.1. 클라이언트

                           시작 <----+
       ClientHello 전송 |        | HelloRetryRequest 수신
       [K_send = 초기 데이터] |        |
                             v        |
        +->               WAIT_SH ----+
        |                    | ServerHello 수신
        |                    | K_recv = 핸드셰이크
 초기  |                    V
데이터 |                 WAIT_EE
 전송  |                    | EncryptedExtensions 수신
 가능  |          +---------+-------+
        |    PSK  |                 | 인증서 사용
        |    사용 |                 v
        |          |            WAIT_CERT_CR
        |          |        수신 |       | CertificateRequest 수신
        |          | Certificate |       v
        |          |             |    WAIT_CERT
        |          |             |       | Certificate 수신
        |          |             v       v
        |          |              WAIT_CV
        |          |                   | CertificateVerify 수신
        |          +-> WAIT_FINISHED <-+
        |                  | Finished 수신
        +->                | [EndOfEarlyData 전송]
                           | K_send = 핸드셰이크
                           | [Certificate [+ CertificateVerify] 전송]
 여기부터                 | Finished 전송
애플리케이션 데이터 -->   | K_send = K_recv = 애플리케이션
전송 가능                 v
                       연결됨

위에 표시된 전이에서는 클라이언트가 ServerHello 이후 메시지에서 발생한 경고를 평문 또는 초기 데이터 키로 전송할 수 있다는 점에 유의한다. 클라이언트가 이러한 경고를 전송해야 하는 경우 가능하면 먼저 핸드셰이크 키로 키를 다시 설정하는 것이 권고된다.¶

A.2. 서버

                             시작 <-----+
               ClientHello 수신 |         | HelloRetryRequest 전송
                               v         |
                            RECVD_CH ----+
                               | 매개변수 선택
                               v
                            협상됨
                               | ServerHello 전송
                               | K_send = 핸드셰이크
                               | EncryptedExtensions 전송
                               | [CertificateRequest 전송]
여기부터                       | [Certificate + CertificateVerify 전송]
애플리케이션 데이터            | Finished 전송
전송 가능 -->                  | K_send = 애플리케이션
                      +--------+--------+
             0-RTT 없음 |                 | 0-RTT
                      |                 |
  K_recv = 핸드셰이크  |                 | K_recv = 초기 데이터
[복호화 오류 건너뜀]   |    +------> WAIT_EOED --+
                      |    |       수신 |       | EndOfEarlyData 수신
                      |    | 초기 데이터 |       | K_recv = 핸드셰이크
                      |    +------------+       |
                      |                         |
                      +-> WAIT_FLIGHT2 <--------+
                               |
                      +--------+--------+
              인증 없음 |                 | 인증서 기반 클라이언트 인증
                      |                 |
                      |                 v
                      |             WAIT_CERT
                      |        수신 |       | Certificate 수신
                      |       빈    |       v
                      | Certificate |    WAIT_CV
                      |             |       | 수신
                      |             v       | CertificateVerify
                      +-> WAIT_FINISHED <---+
                               | Finished 수신
                               | K_recv = 애플리케이션
                               v
                           연결됨

B.1. 레코드 계층

   enum {
       invalid(0),
       change_cipher_spec(20),
       alert(21),
       handshake(22),
       application_data(23),
       (255)
   } ContentType;

   struct {
       ContentType type;
       ProtocolVersion legacy_record_version;
       uint16 length;
       opaque fragment[TLSPlaintext.length];
   } TLSPlaintext;

   struct {
       opaque content[TLSPlaintext.length];
       ContentType type;
       uint8 zeros[length_of_padding];
   } TLSInnerPlaintext;

   struct {
       ContentType opaque_type = application_data; /* 23 */
       ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
       uint16 length;
       opaque encrypted_record[TLSCiphertext.length];
   } TLSCiphertext;

B.2. 경고 메시지

   enum { warning(1), fatal(2), (255) } AlertLevel;

   enum {
       close_notify(0),
       unexpected_message(10),
       bad_record_mac(20),
       decryption_failed_RESERVED(21),
       record_overflow(22),
       decompression_failure_RESERVED(30),
       handshake_failure(40),
       no_certificate_RESERVED(41),
       bad_certificate(42),
       unsupported_certificate(43),
       certificate_revoked(44),
       certificate_expired(45),
       certificate_unknown(46),
       illegal_parameter(47),
       unknown_ca(48),
       access_denied(49),
       decode_error(50),
       decrypt_error(51),
       export_restriction_RESERVED(60),
       protocol_version(70),
       insufficient_security(71),
       internal_error(80),
       inappropriate_fallback(86),
       user_canceled(90),
       no_renegotiation_RESERVED(100),
       missing_extension(109),
       unsupported_extension(110),
       certificate_unobtainable_RESERVED(111),
       unrecognized_name(112),
       bad_certificate_status_response(113),
       bad_certificate_hash_value_RESERVED(114),
       unknown_psk_identity(115),
       certificate_required(116),
       general_error(117),
       no_application_protocol(120),
       (255)
   } AlertDescription;

   struct {
       AlertLevel level;
       AlertDescription description;
   } Alert;

B.3. 핸드셰이크 프로토콜

   enum {
       hello_request_RESERVED(0),
       client_hello(1),
       server_hello(2),
       hello_verify_request_RESERVED(3),
       new_session_ticket(4),
       end_of_early_data(5),
       hello_retry_request_RESERVED(6),
       encrypted_extensions(8),
       certificate(11),
       server_key_exchange_RESERVED(12),
       certificate_request(13),
       server_hello_done_RESERVED(14),
       certificate_verify(15),
       client_key_exchange_RESERVED(16),
       finished(20),
       certificate_url_RESERVED(21),
       certificate_status_RESERVED(22),
       supplemental_data_RESERVED(23),
       key_update(24),
       message_hash(254),
       (255)
   } HandshakeType;

   struct {
       HandshakeType msg_type;    /* 핸드셰이크 유형 */
       uint24 length;             /* 메시지에 남은 바이트 */
       select (Handshake.msg_type) {
           case client_hello:          ClientHello;
           case server_hello:          ServerHello;
           case end_of_early_data:     EndOfEarlyData;
           case encrypted_extensions:  EncryptedExtensions;
           case certificate_request:   CertificateRequest;
           case certificate:           Certificate;
           case certificate_verify:    CertificateVerify;
           case finished:              Finished;
           case new_session_ticket:    NewSessionTicket;
           case key_update:            KeyUpdate;
       };
   } Handshake;

   uint16 ProtocolVersion;
   opaque Random[32];

   uint8 CipherSuite[2];    /* 암호 스위트 선택자 */

   struct {
       ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
       Random random;
       opaque legacy_session_id<0..32>;
       CipherSuite cipher_suites<2..2^16-2>;
       opaque legacy_compression_methods<1..2^8-1>;
       Extension extensions<7..2^16-1>;
   } ClientHello;

   struct {
       ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
       Random random;
       opaque legacy_session_id_echo<0..32>;
       CipherSuite cipher_suite;
       uint8 legacy_compression_method = 0;
       Extension extensions<6..2^16-1>;
   } ServerHello;

   struct {
       ExtensionType extension_type;
       opaque extension_data<0..2^16-1>;
   } Extension;

   enum {
       server_name(0),                             /* RFC 6066, 9261 */
       status_request(5),                          /* RFC 6066, 9846 */
       supported_groups(10),                       /* RFC 7919, 9846 */
       signature_algorithms(13),                   /* RFC 9846 */
       use_srtp(14),                               /* RFC 5764 */
       heartbeat(15),                              /* RFC 6520 */
       application_layer_protocol_negotiation(16), /* RFC 7301 */
       client_certificate_type(19),                /* RFC 7250 */
       server_certificate_type(20),                /* RFC 7250 */
       padding(21),                                /* RFC 7685 */
       compress_certificate(27),                   /* RFC 8879 */
       record_size_limit(28),                      /* RFC 8449 */
       delegated_credential(34),                   /* RFC 9345 */
       supported_ekt_ciphers(39),                  /* RFC 8870 */
       pre_shared_key(41),                         /* RFC 9846 */
       early_data(42),                             /* RFC 9846 */
       supported_versions(43),                     /* RFC 9846 */
       cookie(44),                                 /* RFC 9846 */
       psk_key_exchange_modes(45),                 /* RFC 9846 */
       certificate_authorities(47),                /* RFC 9846 */
       oid_filters(48),                            /* RFC 9846 */
       post_handshake_auth(49),                    /* RFC 9846 */
       signature_algorithms_cert(50),              /* RFC 9846 */
       key_share(51),                              /* RFC 9846 */
       transparency_info(52),                      /* RFC 9162 */
       external_id_hash(55),                       /* RFC 8844 */
       external_session_id(56),                    /* RFC 8844 */
       quic_transport_parameters(57),              /* RFC 9001 */
       ticket_request(58),                         /* RFC 9149 */
       ech_outer_extensions(64768),                /* RFC 9849 */
       encrypted_client_hello(65037),              /* RFC 9849 */
       (65535)
   } ExtensionType;

   struct {
       NamedGroup group;
       opaque key_exchange<1..2^16-1>;
   } KeyShareEntry;

   struct {
       KeyShareEntry client_shares<0..2^16-1>;
   } KeyShareClientHello;

   struct {
       NamedGroup selected_group;
   } KeyShareHelloRetryRequest;

   struct {
       KeyShareEntry server_share;
   } KeyShareServerHello;

   struct {
       uint8 legacy_form = 4;
       opaque X[coordinate_length];
       opaque Y[coordinate_length];
   } UncompressedPointRepresentation;

   enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;

   struct {
       PskKeyExchangeMode ke_modes<1..255>;
   } PskKeyExchangeModes;

   struct {} Empty;

   struct {
       select (Handshake.msg_type) {
           case new_session_ticket:   uint32 max_early_data_size;
           case client_hello:         Empty;
           case encrypted_extensions: Empty;
       };
   } EarlyDataIndication;

   struct {
       opaque identity<1..2^16-1>;
       uint32 obfuscated_ticket_age;
   } PskIdentity;

   opaque PskBinderEntry<32..255>;

   struct {
       PskIdentity identities<7..2^16-1>;
       PskBinderEntry binders<33..2^16-1>;
   } OfferedPsks;

   struct {
       select (Handshake.msg_type) {
           case client_hello: OfferedPsks;
           case server_hello: uint16 selected_identity;
       };
   } PreSharedKeyExtension;

   struct {
       select (Handshake.msg_type) {
           case client_hello:
                ProtocolVersion versions<2..254>;

           case server_hello: /* 및 HelloRetryRequest */
                ProtocolVersion selected_version;
       };
   } SupportedVersions;

   struct {
       opaque cookie<1..2^16-1>;
   } Cookie;

   enum {
       /* RSASSA-PKCS1-v1_5 알고리즘 */
       rsa_pkcs1_sha256(0x0401),
       rsa_pkcs1_sha384(0x0501),
       rsa_pkcs1_sha512(0x0601),

       /* ECDSA 알고리즘 */
       ecdsa_secp256r1_sha256(0x0403),
       ecdsa_secp384r1_sha384(0x0503),
       ecdsa_secp521r1_sha512(0x0603),

       /* 공개 키 OID가 rsaEncryption인 RSASSA-PSS 알고리즘 */
       rsa_pss_rsae_sha256(0x0804),
       rsa_pss_rsae_sha384(0x0805),
       rsa_pss_rsae_sha512(0x0806),

       /* EdDSA 알고리즘 */
       ed25519(0x0807),
       ed448(0x0808),

       /* 공개 키 OID가 RSASSA-PSS인 RSASSA-PSS 알고리즘 */
       rsa_pss_pss_sha256(0x0809),
       rsa_pss_pss_sha384(0x080a),
       rsa_pss_pss_sha512(0x080b),

       /* 레거시 알고리즘 */
       rsa_pkcs1_sha1(0x0201),
       ecdsa_sha1(0x0203),

       /* 예약된 코드 포인트 */
       obsolete_RESERVED(0x0000..0x0200),
       dsa_sha1_RESERVED(0x0202),
       obsolete_RESERVED(0x0204..0x0400),
       dsa_sha256_RESERVED(0x0402),
       obsolete_RESERVED(0x0404..0x0500),
       dsa_sha384_RESERVED(0x0502),
       obsolete_RESERVED(0x0504..0x0600),
       dsa_sha512_RESERVED(0x0602),
       obsolete_RESERVED(0x0604..0x06FF),
       private_use(0xFE00..0xFFFF),
       (0xFFFF)
   } SignatureScheme;

   struct {
       SignatureScheme supported_signature_algorithms<2..2^16-2>;
   } SignatureSchemeList;

   enum {
       unallocated_RESERVED(0x0000),

       /* 타원 곡선 그룹(ECDHE) */
       obsolete_RESERVED(0x0001..0x0016),
       secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
       obsolete_RESERVED(0x001A..0x001C),
       x25519(0x001D), x448(0x001E),

       /* 유한체 그룹(DHE) */
       ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
       ffdhe6144(0x0103), ffdhe8192(0x0104),

       /* 예약된 코드 포인트 */
       ffdhe_private_use(0x01FC..0x01FF),
       ecdhe_private_use(0xFE00..0xFEFF),
       obsolete_RESERVED(0xFF01..0xFF02),
       (0xFFFF)
   } NamedGroup;

   struct {
       NamedGroup named_group_list<2..2^16-1>;
   } NamedGroupList;

   opaque DistinguishedName<1..2^16-1>;

   struct {
       DistinguishedName authorities<3..2^16-1>;
   } CertificateAuthoritiesExtension;

   struct {
       opaque certificate_extension_oid<1..2^8-1>;
       opaque certificate_extension_values<0..2^16-1>;
   } OIDFilter;

   struct {
       OIDFilter filters<0..2^16-1>;
   } OIDFilterExtension;

   struct {} PostHandshakeAuth;

   struct {
       Extension extensions<0..2^16-1>;
   } EncryptedExtensions;

   struct {
       opaque certificate_request_context<0..2^8-1>;
       Extension extensions<0..2^16-1>;
   } CertificateRequest;

   enum {
       X509(0),
       OpenPGP_RESERVED(1),
       RawPublicKey(2),
       (255)
   } CertificateType;

   struct {
       select (certificate_type) {
           case RawPublicKey:
             /* RFC 7250의 ASN.1_subjectPublicKeyInfo */
             opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;

           case X509:
             opaque cert_data<1..2^24-1>;
       };
       Extension extensions<0..2^16-1>;
   } CertificateEntry;

   struct {
       opaque certificate_request_context<0..2^8-1>;
       CertificateEntry certificate_list<0..2^24-1>;
   } Certificate;

   struct {
       SignatureScheme algorithm;
       opaque signature<0..2^16-1>;
   } CertificateVerify;

   struct {
       opaque verify_data[Hash.length];
   } Finished;

   struct {
       uint32 ticket_lifetime;
       uint32 ticket_age_add;
       opaque ticket_nonce<0..255>;
       opaque ticket<1..2^16-1>;
       Extension extensions<0..2^16-1>;
   } NewSessionTicket;

   struct {} EndOfEarlyData;

   enum {
       update_not_requested(0), update_requested(1), (255)
   } KeyUpdateRequest;

   struct {
       KeyUpdateRequest request_update;
   } KeyUpdate;

B.4. 암호 스위트

암호 스위트는 HKDF와 함께 사용할 AEAD 알고리즘과 해시 알고리즘의 쌍을 정의한다. 암호 스위트 이름은 다음 명명 규칙을 따른다.¶

   CipherSuite TLS_AEAD_HASH = VALUE;

이 명세는 TLS 1.3에서 사용할 다음 암호 스위트를 정의한다.¶

대응하는 AEAD 알고리즘 AEAD_AES_128_GCM, AEAD_AES_256_GCM 및 AEAD_AES_128_CCM은 [RFC5116]에 정의되어 있다. AEAD_CHACHA20_POLY1305는 [RFC8439]에 정의되어 있다. AEAD_AES_128_CCM_8은 [RFC6655]에 정의되어 있다. 대응하는 해시 알고리즘은 [SHS]에 정의되어 있다.¶

TLS 1.3은 이전 TLS 버전과 동일한 암호 스위트 공간을 사용하지만, TLS 1.3 암호 스위트는 대칭 암호만 지정하는 방식으로 다르게 정의되며 TLS 1.2에서 사용할 수 없다. 마찬가지로 TLS 1.2 이하의 암호 스위트는 TLS 1.3과 함께 사용할 수 없다.¶

새로운 암호 스위트 값은 섹션 11에 설명된 대로 IANA가 할당한다.¶

C.1. 난수 생성 및 시드 설정

TLS에는 암호학적으로 안전한 의사 난수 생성기 (CSPRNG)가 필요하다. 성능이 우수하고 적절히 안전한 CSPRNG는 대부분의 운영 체제에서 제공되거나 암호화 라이브러리에서 가져올 수 있다. 새로 만드는 것보다 기존 CSPRNG 구현을 사용하는 것이 권고된다. 적절한 라이선스 조건으로 제공되는 충분한 암호화 라이브러리가 이미 많이 있다. 이러한 라이브러리가 만족스럽지 않다면 [RFC4086]에서 난수 값 생성에 관한 지침을 제공한다.¶

TLS는 난수 값을 (1) ClientHello 및 ServerHello의 공개 Random 값과 같은 공개 프로토콜 필드와 (2) 키 자료 생성에 사용한다. CSPRNG가 올바르게 작동한다면 출력에서 CSPRNG 상태를 알아내는 것이 현실적으로 불가능하므로 보안 문제가 되지 않는다. 그러나 CSPRNG가 손상된 경우 공격자가 공개 출력을 사용해 CSPRNG 내부 상태를 알아내고 그 결과 키 자료를 예측할 수 있으며, 이는 [CHECKOWAY] 및 [DSA-1571-1]에 기록되어 있다.¶

구현은 공개 값과 비공개 값을 생성할 때 별도의 CSPRNG를 사용하여 이러한 형태의 공격에 대한 추가 보안을 제공할 수 있다.¶

[RFC8937]은 보안 프로토콜 구현이 장기 개인 키와 결정적 서명 함수를 사용해 (의사) 난수 생성기를 보강하는 방법을 설명한다. 이는 손상되었거나 다른 방식으로 무력화된 난수 생성기의 무작위성을 개선한다.¶

C.2. 인증서 및 인증

구현은 인증서의 무결성을 검증할 책임이 있으며 일반적으로 인증서 폐기 메시지를 지원해야 한다. 섹션 4.5.1.1을 참조한다. 애플리케이션 프로필에서 구체적으로 달리 나타내지 않는 한, 신뢰할 수 있는 인증 기관(CA)이 올바르게 서명했는지 확인하도록 인증서를 항상 검증해야 한다. 신뢰 앵커의 선택과 추가는 매우 신중하게 수행해야 한다. 사용자는 인증서와 신뢰 앵커에 관한 정보를 볼 수 있어야 한다. 애플리케이션은 최소 및 최대 키 크기도 강제하는 것이 권고된다. 예를 들어 2048비트 RSA 또는 224비트 ECDSA보다 약한 키나 서명을 포함하는 인증 경로는 안전한 애플리케이션에 적합하지 않다.¶

일부 프로토콜에서는 클라이언트 모드와 서버 모드 모두에서 동일한 인증서를 사용하는 것이 일반적이라는 점에 유의한다. 이 설정은 광범위하게 분석되지 않았으며, 이 경우 상위 수준 의미론에 모호함이 없도록 보장하는 것은 상위 수준 프로토콜의 책임이다.¶

C.3. 구현상의 함정

구현 경험에 따르면 이전 TLS 명세의 특정 부분은 이해하기 쉽지 않았고 상호 운용성 및 보안 문제의 원인이 되었다. 이러한 영역 중 많은 부분이 이 문서에서 명확해졌지만, 이 부록에는 구현자가 특별히 주의해야 할 가장 중요한 사항을 간단히 나열한다.¶

TLS 프로토콜 문제:¶

• 여러 TLS 레코드로 조각화된 핸드셰이크 메시지를 올바르게 처리하는가 (섹션 5.1 참조)? 여러 개의 작은 조각으로 분할된 ClientHello 같은 극단적인 경우도 올바르게 처리하는가? 최대 조각 크기를 초과하는 핸드셰이크 메시지를 조각화하는가? 특히 Certificate 및 CertificateRequest 핸드셰이크 메시지는 조각화가 필요할 만큼 클 수 있다. [RFC8879]에 정의된 인증서 압축을 사용하면 조각화 위험을 줄일 수 있다.¶

• 암호화되지 않은 모든 TLS 레코드에서 TLS 레코드 계층 버전 번호를 무시하는가 (부록 E 참조)?¶

• TLS 1.3 이상을 지원하는 모든 가능한 구성에서 SSL, RC4, EXPORT 암호 및 MD5 ("signature_algorithms" 확장을 통한 지원)를 완전히 제거하고, 이러한 사용 중단된 기능을 사용하려는 시도가 올바르게 실패하도록 보장했는가 (부록 E 참조)?¶

• 알 수 없는 확장을 포함하여 ClientHello의 TLS 확장을 올바르게 처리하는가?¶

• 서버가 클라이언트 인증서를 요청했지만 적합한 인증서를 사용할 수 없는 경우 전체 메시지를 생략하는 대신 빈 Certificate 메시지를 올바르게 전송하는가 (섹션 4.5.1 참조)?¶

• AEAD-Decrypt에서 생성한 평문 조각을 처리하고 끝에서부터 ContentType을 검색할 때, 피어가 모두 0으로 이루어진 잘못된 평문을 전송한 경우 평문의 시작 지점을 지나서 검색하지 않도록 하는가?¶

• ClientHello에서 인식하지 못하는 암호 스위트 (섹션 4.2.2), hello 확장 (섹션 4.3), 명명된 그룹 (섹션 4.3.7), 키 공유 (섹션 4.3.8), 지원되는 버전 (섹션 4.3.1) 및 서명 알고리즘 (섹션 4.3.3)을 올바르게 무시하는가?¶

• 서버로서 호환되는 비대칭 키 교환 그룹을 지원하지만 "key_share" 확장에서 이를 예상하여 제공하지 않은 클라이언트에 HelloRetryRequest를 전송하는가? 클라이언트로서 서버의 HelloRetryRequest를 올바르게 처리하는가?¶

암호화 세부사항:¶

• 타이밍 공격 [TIMING]을 방지하기 위해 어떤 대응책을 사용하는가?¶

• 디피-헬먼 키 교환을 사용할 때 협상된 키의 선행 0바이트를 올바르게 보존하는가 (섹션 7.4.1 참조)?¶

• TLS 클라이언트가 서버에서 전송한 디피-헬먼 매개변수를 수락할 수 있는지 검사하는가 (섹션 4.3.8.1 참조)?¶

• 디피-헬먼 개인 값, ECDSA "k" 매개변수 및 기타 보안에 중요한 값을 생성할 때 강력하고 무엇보다 올바르게 시드된 난수 생성기를 사용하는가 (부록 C.1 참조)? 구현은 [RFC6979]에 명세된 "결정적 ECDSA"를 구현하는 것이 권고된다. 결정적 ECDSA 및 EdDSA처럼 완전히 결정적인 타원 곡선 암호화(ECC) 서명은 쉽게 접근할 수 있는 사물 인터넷(IoT) 장치에서 특정 부채널 및 오류 주입 공격에 취약할 수 있다는 점에 유의한다.¶

• 디피-헬먼 공개 키 값과 공유 비밀값을 그룹 크기에 맞도록 0으로 패딩하는가 (섹션 4.3.8.1 및 섹션 7.4.1 참조)?¶

• RSA-CRT 키 유출 [FW15]을 방지하기 위해 서명을 생성한 후 검증하는가?¶

C.4. 클라이언트 및 서버 추적 방지

클라이언트는 여러 연결에서 하나의 티켓을 재사용하지 않는 것이 권고된다. 티켓을 재사용하면 수동 관찰자가 서로 다른 연결을 연관 지을 수 있다. 티켓을 발행하는 서버는 클라이언트가 사용할 수 있는 연결 수만큼 티켓을 제공하는 것이 권고된다. 예를 들어 HTTP/1.1 [RFC9112]을 사용하는 웹 브라우저는 서버에 6개의 연결을 열 수 있다. 서버는 모든 연결에서 새 티켓을 발행하는 것이 권고된다. 이를 통해 클라이언트가 새 연결을 생성할 때 항상 새 티켓을 사용할 수 있다.¶

서버에 티켓을 제공하면 서버도 서로 다른 연결을 연관 지을 수 있다. 이는 티켓 재사용 여부와 관계없이 가능하다. 클라이언트 애플리케이션은 서로 연관되지 않아야 하는 연결 사이에서 티켓을 제공하지 않는 것이 권고된다. 예를 들어 [FETCH]는 웹 브라우저의 캐시 조회를 분리하기 위한 네트워크 파티션 키를 정의한다.¶

외부 식별자의 레이블은 사용자의 신원에 관한 추가 정보를 제공하지 않도록 선택하는 것이 권고된다. 예를 들어 레이블에 이메일 주소가 포함되면 암호화되는 클라이언트의 Certificate와 달리 수동 공격자가 사용자를 쉽게 식별할 수 있다. 이 위험을 방지할 수 있는 잠재적 방법에는 (1) 무작위 신원 레이블 사용, (2) 서버가 알고 있는 키로 신원을 미리 암호화, (3) 암호화된 클라이언트 헬로 [RFC9849] 사용 등이 있다.¶

외부 PSK 식별자를 여러 연결에 사용하면 일반적으로 외부 관찰자가 연결 간에 클라이언트 및/또는 서버를 추적할 수 있다. 암호화된 클라이언트 헬로 [RFC9849]를 사용하면 이 위험을 완화할 수 있으며, PSK 식별자를 순환하거나 암호화하는 TLS 외부 메커니즘도 같은 효과를 제공할 수 있다.¶

C.5. 인증되지 않은 동작

이전 TLS 버전은 익명 디피-헬먼을 기반으로 명시적으로 인증되지 않은 암호 스위트를 제공했다. 이러한 모드는 TLS 1.3에서 사용 중단되었다. 그러나 다음을 포함한 여러 방법으로 검증 가능한 서버 인증을 제공하지 않는 매개변수를 여전히 협상할 수 있다.¶

• 원시 공개 키 [RFC7250].¶

• 인증서에 포함된 공개 키를 사용하되 인증서 체인이나 그 내용은 검증하지 않는 방식.¶

두 기법 모두 단독으로 사용하면 중간자 공격에 취약하므로 일반적인 용도로 안전하지 않다. 그러나 서버 공개 키의 대역 외 검증, 최초 사용 시 신뢰 또는 채널 바인딩 같은 메커니즘을 통해 이러한 연결을 외부 인증 메커니즘에 결합할 수도 있다 (다만 [RFC5929]에 설명된 채널 바인딩은 TLS 1.3에 정의되어 있지 않음). 이러한 메커니즘을 사용하지 않으면 연결은 능동적인 중간자 공격에 대해 아무런 보호를 제공하지 않는다. 명시적인 구성이나 특정 애플리케이션 프로필이 없는 경우 애플리케이션은 이러한 방식으로 TLS를 사용해서는 안 된다.¶

E.1. 이전 서버와의 협상

TLS 1.3을 지원하지 않는 서버와 협상하려는 TLS 1.3 클라이언트는 ClientHello.legacy_version에 0x0303(TLS 1.2)을 포함하되 "supported_versions" 확장에는 올바른 버전을 포함하는 일반적인 TLS 1.3 ClientHello를 전송한다. 서버가 TLS 1.3을 지원하지 않으면 이전 버전 번호를 포함하는 ServerHello로 응답한다. 클라이언트가 이 버전 사용에 동의하면 협상은 협상된 프로토콜에 적합한 방식으로 진행된다. 재개를 위해 티켓을 사용하는 클라이언트는 이전에 협상한 버전을 사용해 연결을 시작하는 것이 권고된다.¶

0-RTT 데이터는 이전 서버와 호환되지 않으며, 서버가 TLS 1.3을 지원한다는 사실을 알지 못하는 경우 전송하지 않는 것이 권고된다. 부록 E.3을 참조한다.¶

서버가 선택한 버전을 클라이언트가 지원하지 않거나 수락할 수 없는 경우 클라이언트는 "protocol_version" 경고와 함께 핸드셰이크를 반드시 중단해야 한다.¶

일부 레거시 서버 구현은 TLS 명세를 올바르게 구현하지 않아 인식하지 못하는 TLS 확장이나 버전을 만나면 연결을 중단하는 것으로 알려져 있다. 결함이 있는 서버와의 상호 운용성은 이 문서의 범위를 벗어나는 복잡한 주제이다. 하위 호환 연결을 협상하려면 여러 번 연결을 시도해야 할 수도 있지만, 이 방식은 다운그레이드 공격에 취약하므로 권고되지 않는다.¶

E.2. 이전 클라이언트와의 협상

TLS 서버는 자신이 지원하는 가장 높은 버전보다 작은 버전 번호를 나타내는 ClientHello도 수신할 수 있다. "supported_versions" 확장이 존재하면 서버는 섹션 4.3.1에 설명된 대로 해당 확장을 사용하여 반드시 협상해야 한다. "supported_versions" 확장이 존재하지 않으면 서버는 ClientHello.legacy_version과 TLS 1.2 중 더 낮은 버전을 반드시 협상해야 한다. 예를 들어 서버가 TLS 1.0, 1.1 및 1.2를 지원하고 legacy_version이 TLS 1.0이면 서버는 TLS 1.0 ServerHello로 진행한다. "supported_versions" 확장이 없고 서버가 ClientHello.legacy_version보다 높은 버전만 지원하는 경우, 서버는 "protocol_version" 경고와 함께 핸드셰이크를 반드시 중단해야 한다.¶

이전 TLS 버전은 모든 경우의 레코드 계층 버전 번호 값 (TLSPlaintext.legacy_record_version)을 명확하게 명세하지 않았다는 점에 유의한다. 서버는 이 필드에서 다양한 TLS 1.x 버전을 수신하지만 그 값은 항상 반드시 무시해야 한다.¶

E.3. 0-RTT 하위 호환성

0-RTT 데이터는 이전 서버와 호환되지 않는다. 이전 서버는 ClientHello에 이전 버전의 ServerHello로 응답하지만, 0-RTT 데이터를 올바르게 건너뛰지 못하므로 핸드셰이크 완료에 실패한다. 이는 특히 다중 서버 배포를 대상으로 클라이언트가 0-RTT를 사용하려 할 때 문제를 일으킬 수 있다. 예를 들어 일부 서버는 TLS 1.3을 구현하고 일부는 TLS 1.2를 구현하는 방식으로 TLS 1.3을 점진적으로 배포하거나, TLS 1.3 배포가 TLS 1.2로 다운그레이드될 수 있다.¶

0-RTT 데이터를 전송하려는 클라이언트는 TLS 1.2 이하의 ServerHello를 수신하면 연결을 반드시 실패시켜야 한다. 그런 다음 0-RTT를 비활성화한 상태로 연결을 다시 시도할 수 있다. 다운그레이드 공격을 방지하기 위해 클라이언트는 TLS 1.3이 아니라 0-RTT만 비활성화하는 것이 권고된다.¶

이 오류 조건을 방지하려면 다중 서버 배포는 0-RTT를 활성화하기 전에 0-RTT가 없는 TLS 1.3을 균일하고 안정적으로 배포하는 것이 권고된다.¶

E.4. 미들박스 호환 모드

현장 측정 [Ben17a] [Ben17b] [Res17a] [Res17b]에 따르면 상당수 미들박스는 TLS 클라이언트/서버 쌍이 TLS 1.3을 협상할 때 잘못 동작한다. 구현은 TLS 1.3 핸드셰이크를 TLS 1.2 핸드셰이크와 더 비슷하게 보이게 하여 이러한 미들박스를 통과해 연결할 가능성을 높일 수 있다.¶

• 클라이언트는 섹션 4.2.2의 legacy_session_id 섹션에 설명된 대로 ClientHello에 항상 비어 있지 않은 세션 ID를 제공한다.¶

• 초기 데이터를 제공하지 않는 경우 클라이언트는 두 번째 플라이트 직전에 더미 change_cipher_spec 레코드 (섹션 5의 세 번째 단락 참조)를 전송한다. 이는 두 번째 ClientHello 전이나 암호화된 핸드셰이크 플라이트 전에 올 수 있다. 초기 데이터를 제공하는 경우 이 레코드는 첫 번째 ClientHello 직후에 배치된다.¶

• 서버는 첫 번째 핸드셰이크 메시지 직후에 더미 change_cipher_spec 레코드를 전송한다. 이는 ServerHello 또는 HelloRetryRequest 뒤에 올 수 있다.¶

이러한 변경을 함께 적용하면 TLS 1.3 핸드셰이크가 TLS 1.2 세션 재개와 비슷해져 미들박스를 통과해 성공적으로 연결할 가능성이 높아진다. 이 "호환 모드"는 부분적으로 협상된다. 클라이언트는 세션 ID를 제공할지 선택할 수 있으며, 서버는 이를 그대로 반환해야 한다. 피어가 무시해야 하므로 어느 쪽이든 핸드셰이크 중 언제든 change_cipher_spec을 전송할 수 있지만, 클라이언트가 비어 있지 않은 세션 ID를 전송한 경우 서버는 이 부록에 설명된 대로 change_cipher_spec을 반드시 전송해야 한다.¶

E.5. 하위 호환성과 관련된 보안 제한

이전 TLS 버전의 사용을 협상하는 구현은 가능한 경우 순방향 비밀성을 제공하는 AEAD 암호 스위트를 선호하는 것이 권고된다.¶

RC4 암호 스위트의 보안은 [RFC7465]에 제시된 이유로 충분하지 않은 것으로 간주된다. 구현은 어떤 이유로든 어떤 TLS 버전에서도 RC4 암호 스위트를 제공하거나 협상해서는 안 된다.¶

이전 TLS 버전은 매우 낮은 강도의 암호 사용을 허용했다. 강도가 112비트 미만인 암호는 어떤 이유로든 어떤 TLS 버전에서도 제공하거나 협상해서는 안 된다.¶

SSL 2.0 [SSL2], SSL 3.0 [RFC6101], TLS 1.0 [RFC2246] 및 TLS 1.1 [RFC4346]의 보안은 [RFC6176], [RFC7568] 및 [RFC8996]에 열거된 이유로 충분하지 않은 것으로 간주되며, 어떤 이유로든 협상해서는 안 된다.¶

구현은 SSL 버전 2.0 호환 CLIENT-HELLO를 전송해서는 안 된다. 구현은 SSL 버전 2.0 호환 CLIENT-HELLO를 사용해 TLS 1.3 이상을 협상해서는 안 된다. 구현이 이전 TLS 버전을 협상하기 위해 SSL 버전 2.0 호환 CLIENT-HELLO를 수락하는 것은 권고되지 않는다.¶

구현은 ClientHello.legacy_version 및 ServerHello.legacy_version에 0x0303을 반드시 사용해야 한다. 다른 버전 번호가 있는 Hello 메시지를 수신한 구현은 섹션 4.2.2 및 섹션 4.2.3에 설명된 대로 핸드셰이크를 반드시 중단해야 한다.¶

구현은 0x0300 미만의 버전이 있는 레코드를 전송해서는 안 된다. 구현은 0x0300 미만의 버전이 있는 레코드를 수락하지 않는 것이 권고된다 (다만 레코드 버전 번호를 완전히 무시하는 경우 의도치 않게 수락할 수 있음).¶

구현은 [RFC6066]의 섹션 7에 정의된 Truncated HMAC 확장을 사용해서는 안 된다. 이 확장은 AEAD 알고리즘에 적용되지 않으며 일부 상황에서 안전하지 않은 것으로 확인되었기 때문이다.¶

F.1. 핸드셰이크

TLS 핸드셰이크는 단방향 인증(서버만)과 상호 인증 (클라이언트와 서버) 기능을 모두 제공하기 위한 인증된 키 교환(AKE) 프로토콜이다. 핸드셰이크가 완료되면 각 측은 다음 값에 대한 자신의 관점을 출력한다.¶

• 작업 키 집합을 유도할 수 있는 "세션 키" 집합(주 비밀값에서 유도된 여러 비밀값). 초기 데이터를 사용하는 경우 초기 비밀값에서도 비밀값이 유도된다는 점에 유의한다. 이러한 비밀값은 아래에서 설명한 것처럼 주 비밀값에서 유도된 비밀값보다 다소 약한 속성을 가진다.¶

• 암호화 매개변수 집합(알고리즘 등).¶

• 통신 당사자의 신원.¶

공격자는 당사자 간 통신에 사용되는 네트워크를 완전히 제어하는 능동 네트워크 공격자라고 가정한다 [RFC3552]. 이러한 조건에서도 핸드셰이크는 아래에 나열된 속성을 제공해야 한다. 이러한 속성은 반드시 서로 독립적이지는 않으며, 프로토콜 사용자의 요구사항을 반영한다.¶

동일한 세션 키 설정:

각 엔드포인트에서 핸드셰이크가 성공적으로 완료되면 핸드셰이크 양쪽은 동일한 세션 키 집합을 출력해야 한다 ([CK01]의 정의 1, 제1부 참조).¶

세션 키의 비밀성:

공유 세션 키는 통신 당사자만 알고 있어야 하며 공격자는 알 수 없어야 한다 ([CK01]의 정의 1, 제2부 참조). 단방향 인증 연결에서 공격자가 서버와 자체 세션 키를 설정할 수 있지만, 그 세션 키는 클라이언트가 설정한 것과 구별된다는 점에 유의한다.¶

피어 인증:

피어 신원에 대한 클라이언트의 관점은 서버의 신원을 반영해야 한다. 클라이언트가 인증된 경우 피어 신원에 대한 서버의 관점은 클라이언트의 신원과 일치해야 한다.¶

세션 키의 고유성:

서로 다른 두 핸드셰이크는 서로 다르고 관련 없는 세션 키를 생성해야 한다. 하나의 핸드셰이크에서 생성된 개별 세션 키도 서로 다르고 독립적이어야 한다.¶

다운그레이드 보호:

암호화 매개변수는 양쪽에서 동일해야 하며 공격이 없을 때 피어들이 통신했다면 선택했을 매개변수와 같아야 한다 ([BBFGKZ16]의 정의 8 및 9 참조).¶

장기 키에 대한 순방향 비밀성:

핸드셰이크가 완료된 후 장기 키 자료 (이 경우 인증서 기반 인증 모드의 서명 키 또는 비대칭 키 교환 모드와 함께 사용하는 PSK의 외부/재개 PSK)가 침해되더라도, 세션 키 자체와 세션 키를 재생성하는 데 사용할 수 있는 모든 자료가 삭제된 경우 세션 키의 보안은 침해되지 않는다 ([DOW92] 참조). 특히 키 공유값에 대응하는 개인 키, 공유 비밀값 및 binder_key, resumption_secret, resumption_secret에서 유도된 PSK를 제외하고 TLS 키 스케줄에서 유도된 키도 삭제해야 한다. PSK를 "psk_ke" PskKeyExchangeMode에서 사용하는 경우 순방향 비밀성 속성이 충족되지 않는다. 임시 또는 연결별로 사용하려던 키나 비밀값을 삭제하지 않으면 사실상 보호해야 할 추가 장기 키가 만들어진다. 이러한 장기 키가 침해되면 핸드셰이크가 완료된 후에도 연결 트래픽의 보호가 상실될 수 있다.¶

키 침해 가장(KCI) 저항성:

인증서를 사용하는 상호 인증 연결에서는 한 당사자의 장기 비밀값이 침해되더라도 해당 연결에서 그 당사자가 피어를 인증하는 기능이 깨져서는 안 된다 ([HGFS15] 참조). 예를 들어 클라이언트의 서명 키가 침해되더라도 이후 핸드셰이크에서 임의의 서버가 해당 클라이언트에 자신을 사칭할 수 없어야 한다.¶

엔드포인트 신원 보호:

서버의 신원(인증서)은 수동 공격자로부터 보호되어야 한다. 클라이언트의 신원(인증서)은 수동 및 능동 공격자 모두로부터 보호되어야 한다. 기밀성을 제공하지 않는 암호 스위트에서는 이 속성이 성립하지 않는다. 이 명세는 그러한 암호 스위트를 정의하지 않지만 다른 문서에서 정의할 수 있다.¶

비형식적으로 TLS 1.3의 서명 기반 모드는 비대칭 키 교환으로 설정된 고유하고 비밀인 공유 키를 제공하며, 핸드셰이크 트랜스크립트에 대한 서버의 서명으로 인증하고 MAC을 통해 서버의 신원과 결합한다. 클라이언트가 인증서로 인증되는 경우 클라이언트도 핸드셰이크 트랜스크립트에 서명하고 두 신원에 결합된 MAC을 제공한다. [SIGMA]는 이러한 유형의 키 교환 프로토콜 설계와 분석을 설명한다. 각 연결에 새로운 비대칭 키를 사용하면 출력 키는 순방향 비밀성을 가진다.¶

외부 PSK와 재개 PSK는 장기 공유 비밀값에서 연결별로 고유한 단기 세션 키 집합을 부트스트랩한다. 이 비밀값은 이전 핸드셰이크에서 설정되었을 수 있다. 비대칭 키 설정과 함께 PSK를 사용하면 이러한 세션 키도 순방향 비밀성을 가진다. 재개 PSK는 연결 N에서 계산하고 연결 N+1을 형성하는 데 필요한 재개 비밀값이 연결 N에서 사용하는 트래픽 키와 분리되도록 설계되어 연결 간 순방향 비밀성을 제공한다. 또한 동일한 연결에서 여러 티켓을 설정하면 서로 다른 키와 연관되므로 한 티켓과 연관된 PSK가 침해되어도 다른 티켓과 연관된 PSK로 설정한 연결이 침해되지 않는다. 이 속성은 티켓이 자체 암호화된 경우보다 데이터베이스에 저장되어 삭제할 수 있는 경우에 더 의미가 있다.¶

순방향 비밀성은 키 유출의 영향을 한 방향으로 제한한다 (시간 T2의 키 침해가 T1 < T2인 시간 T1의 일부 키를 침해하지 않음). 반대 방향의 보호 (시간 T1의 침해가 시간 T2의 키를 침해하지 않음)는 비대칭 키 설정을 다시 수행하여 얻을 수 있다. 장기 인증 키가 침해된 경우 비대칭 키 설정을 사용하는 전체 핸드셰이크는 수동 공격자에 대한 보호를 제공한다. resumption_secret이 침해된 경우 비대칭 키 설정을 사용하는 재개 핸드셰이크는 수동 공격자에 대한 보호를 제공하고, 비대칭 키 설정을 사용하는 전체 핸드셰이크는 능동 공격자에 대한 보호를 제공한다. 트래픽 비밀값이 침해된 경우 비대칭 키 설정을 사용하는 모든 핸드셰이크가 능동 공격자에 대한 보호를 제공한다. [RFC7624]의 용어를 사용하면, 비대칭 키 설정을 다시 수행하지 않는 순방향 비밀성은 공격자가 정적 키 유출을 수행하는 것을 막지 못한다. application_traffic_secret_N이 유출되면 공격자는 예를 들어 application_traffic_secret_N+1, application_traffic_secret_N+2 등으로 암호화된 데이터를 포함해 해당 연결에서 앞으로 전송되는 모든 데이터를 수동으로 도청할 수 있다. 비대칭 키 설정을 자주 다시 수행하면 공격자가 동적 키 유출 또는 콘텐츠 유출을 수행하도록 강제한다.¶

PSK 바인더 값은 PSK와 현재 핸드셰이크 사이, 그리고 PSK가 설정된 세션(NewSessionTicket 메시지를 통해 설정된 경우)과 현재 세션 사이에 결합을 형성한다. 원래 핸드셰이크 트랜스크립트가 재개 비밀값을 생성하는 값에 반영되므로 이 결합에는 원래 핸드셰이크 트랜스크립트도 전이적으로 포함된다. 이를 위해서는 재개 비밀값을 생성하는 KDF와 바인더를 계산하는 MAC이 모두 충돌 저항성을 가져야 한다. 자세한 내용은 부록 F.1.1을 참조한다. 참고: 바인더는 다른 PSK의 바인더 값을 포함하지 않지만, 해당 값은 Finished MAC에 포함된다.¶

참고: 이 명세는 현재 서버가 인증서 기반이 아닌 핸드셰이크(예: PSK)에서 CertificateRequest 메시지를 전송하는 것을 허용하지 않는다. 향후 이 제한이 완화되면 클라이언트의 서명은 서버 인증서를 직접 포함하지 않는다. 그러나 PSK가 NewSessionTicket을 통해 설정된 경우 클라이언트의 서명은 PSK 바인더를 통해 서버 인증서를 전이적으로 포함한다. [PSK-FINISHED]는 서버 인증서에 결합하지 않는 구성에 대한 구체적인 공격을 설명한다 ([Kraw16]도 참조). 클라이언트가 서로 다른 두 엔드포인트와 동일한 PSK/키 ID 쌍을 공유할 가능성이 있는 경우 인증서 기반 클라이언트 인증을 사용하는 것은 안전하지 않다. 달리 규정하는 다른 명세가 없는 경우 구현은 외부 PSK를 클라이언트 또는 서버의 인증서 기반 인증과 결합해서는 안 된다. [RFC8773]은 이를 허용하는 확장을 제공하지만 이 명세만큼 분석되지 않았다.¶

익스포터를 사용하면 고유한 세션 키에서 생성되므로 고유하고 비밀인 값을 생성한다. 서로 다른 레이블과 콘텍스트로 계산된 익스포터는 계산적으로 독립적이므로 하나에서 다른 하나를 계산하거나 내보낸 값에서 세션 비밀값을 계산하는 것은 현실적으로 불가능하다. 참고: 익스포터는 임의 길이 값을 생성할 수 있다. 익스포터를 채널 바인딩으로 사용하는 경우 내보낸 값은 충돌 저항성을 제공할 만큼 충분히 커야 한다. TLS 1.3에서 제공하는 익스포터는 각각 초기 트래픽 키 및 애플리케이션 트래픽 키와 동일한 Handshake Context에서 유도되므로 비슷한 보안 속성을 가진다. 클라이언트 인증서를 포함하지 않는다는 점에 유의한다. 클라이언트 인증서에 결합하려는 향후 애플리케이션은 전체 핸드셰이크 트랜스크립트를 포함하는 새로운 익스포터를 정의해야 할 수 있다.¶

모든 핸드셰이크 모드에서 Finished MAC과 존재하는 경우 서명은 다운그레이드 공격을 방지한다. 또한 섹션 4.2.3에 설명된 대로 무작위 논스의 특정 바이트를 사용하면 이전 TLS 버전으로의 다운그레이드를 탐지할 수 있다. TLS 1.3과 다운그레이드에 관한 자세한 내용은 [BBFGKZ16]을 참조한다.¶

클라이언트와 서버가 공유 키를 설정하기에 충분한 정보를 교환하는 즉시 나머지 핸드셰이크는 암호화되므로, 계산된 공유 키가 인증되지 않았더라도 수동 공격자에 대한 보호를 제공한다. 서버가 클라이언트보다 먼저 인증하므로 클라이언트는 서버에 자신을 인증하는 경우 인증된 서버에만 신원을 공개하도록 보장할 수 있다. 길이로 인해 신원 정보가 누출되는 것을 방지하려면 구현이 핸드셰이크 중 제공된 레코드 패딩 메커니즘을 사용해야 한다는 점에 유의한다. 클라이언트가 제안한 PSK 식별자와 서버가 선택한 식별자는 암호화되지 않는다.¶

F.2. 레코드 계층

레코드 계층은 핸드셰이크가 양방향 암호화 키와 논스를 유도하는 데 사용할 수 있는 강력한 트래픽 비밀값을 생성하는 데 의존한다. 이것이 참이고 키를 섹션 5.5에 표시된 양보다 많은 데이터에 사용하지 않는다고 가정하면 레코드 계층은 다음 보장을 제공해야 한다.¶

기밀성:

공격자는 특정 레코드의 평문 내용을 알아낼 수 없어야 한다.¶

무결성:

공격자는 수신자가 수락할 기존 레코드와 다른 새 레코드를 만들 수 없어야 한다.¶

순서 보호/재전송 불가능성:

공격자는 수신자가 이미 수락한 레코드를 다시 수락하게 하거나, 레코드 N을 먼저 처리하지 않고 레코드 N+1을 수락하게 할 수 없어야 한다.¶

길이 은폐:

외부 길이가 주어진 레코드에서 공격자는 레코드 중 어느 정도가 콘텐츠이고 어느 정도가 패딩인지 알아낼 수 없어야 한다.¶

키 변경 후 순방향 비밀성:

섹션 4.7.3에 설명된 트래픽 키 갱신 메커니즘을 사용하고 이전 세대 키를 삭제한 경우, 엔드포인트를 침해한 공격자는 이전 키로 암호화된 트래픽을 복호화할 수 없어야 한다.¶

비형식적으로 TLS 1.3은 강력한 키로 평문을 AEAD 보호하여 이러한 속성을 제공한다. AEAD 암호화 [RFC5116]는 데이터의 기밀성과 무결성을 제공한다. 재전송 불가능성은 각 레코드에 별도의 논스를 사용하여 제공되며, 논스는 레코드 시퀀스 번호 (섹션 5.3)에서 유도되고 시퀀스 번호는 양쪽에서 독립적으로 유지된다. 따라서 순서가 뒤바뀌어 전달된 레코드는 AEAD 보호 해제 실패를 일으킨다. 동일한 평문이 동일한 키로 서로 다른 사용자에 의해 반복해서 암호화될 때 (HTTP에서 흔히 발생) 대규모 암호 분석을 방지하기 위해 논스는 시퀀스 번호와 트래픽 키와 함께 유도된 연결별 비밀 초기화 벡터를 혼합하여 구성한다. 이 구성의 분석은 [BT16]을 참조한다.¶

TLS 1.3의 키 재설정 기법 (섹션 7.2 참조)은 [REKEY]에서 설명한 직렬 생성기 구성을 따른다. 이 문서는 키 재설정을 사용하면 키를 재설정하지 않는 경우보다 더 많은 암호화에 키를 사용할 수 있음을 보여준다. 이는 HKDF-Expand-Label 함수가 의사 난수 함수(PRF)로서 안전하다는 데 의존한다. 또한 이 함수가 실제로 단방향인 한 키 변경 이전의 트래픽 키를 계산하는 것은 불가능하다(순방향 비밀성).¶

TLS는 해당 연결의 트래픽 비밀값이 침해된 후 연결에서 전달되는 데이터에 보안을 제공하지 않는다. 즉, TLS는 트래픽 비밀값에 대해 침해 후 보안/미래 비밀성/후방 비밀성을 제공하지 않는다. 실제로 트래픽 비밀값을 알아낸 공격자는 해당 연결의 향후 모든 트래픽 비밀값을 계산할 수 있다. 이러한 보장을 원하는 시스템은 새로운 핸드셰이크를 수행하고 비대칭 키 교환을 사용하는 새 연결을 설정해야 한다.¶

F.3. 트래픽 분석

TLS는 암호화된 패킷의 길이와 타이밍을 관찰하는 다양한 트래픽 분석 공격에 취약하다 [CLINIC] [HCJC16]. 고정된 콘텐츠 모음을 호스팅하는 비디오 서버처럼 구분할 수 있는 가능한 메시지 집합이 작은 경우 특히 쉽지만, 더 복잡한 상황에서도 유용한 정보를 제공한다.¶

TLS는 이러한 형태의 공격에 대한 구체적인 방어책을 제공하지 않지만 애플리케이션에서 사용할 수 있는 패딩 메커니즘을 포함한다. AEAD 함수로 보호되는 평문은 콘텐츠와 가변 길이 패딩으로 구성되므로, 애플리케이션은 임의 길이의 암호화된 레코드뿐 아니라 전송 기간과 무전송 기간의 차이를 숨기기 위한 패딩 전용 위장 트래픽도 생성할 수 있다. 패딩은 실제 콘텐츠와 함께 암호화되므로 공격자는 패딩 길이를 직접 알아낼 수 없지만, 레코드 처리 중 노출되는 타이밍 채널을 사용해 간접적으로 측정할 수 있다 (즉, 레코드 처리 시간을 관찰하거나 레코드를 조금씩 전송해 서버 응답을 유발하는 레코드를 확인함). 일반적으로 상수 시간 패딩 제거 함수조차 콘텐츠를 데이터 의존적 함수에 전달할 가능성이 있으므로 이러한 모든 채널을 제거하는 방법은 알려져 있지 않다. 최소한 완전한 상수 시간 서버 또는 클라이언트를 구현하려면 상위 수준 프로토콜도 상수 시간으로 만드는 것을 포함해 애플리케이션 계층 프로토콜 구현과 긴밀하게 협력해야 한다.¶

참고: 강력한 트래픽 분석 방어는 패킷 전송 지연과 트래픽 양 증가로 인해 성능 저하를 일으킬 가능성이 높다.¶

F.4. 부채널 공격

일반적으로 TLS는 부채널 공격 (즉, 타이밍 같은 보조 채널을 통해 통신을 공격하는 방식)에 대한 구체적인 방어책을 제공하지 않으며, 관련 암호화 프리미티브의 구현에 이를 맡긴다. 그러나 TLS의 특정 기능은 부채널 저항성 코드를 더 쉽게 작성할 수 있도록 설계되었다.¶

• MAC 후 암호화 복합 구조를 사용한 이전 TLS 버전과 달리, TLS 1.3은 AEAD 알고리즘만 사용하므로 구현이 이러한 프리미티브의 자체 완결적 상수 시간 구현을 사용할 수 있다.¶

• TLS는 모든 복호화 오류에 통일된 "bad_record_mac" 경고를 사용하여 공격자가 메시지 일부에 대한 단편적인 정보를 얻는 것을 방지한다. 이러한 오류가 발생하면 연결을 종료하여 추가적인 저항성을 제공한다. 새 연결은 서로 다른 암호화 자료를 사용하므로 여러 번의 시도가 필요한 암호화 프리미티브 공격을 방지한다.¶

부채널을 통한 정보 누출은 TLS보다 상위 계층의 애플리케이션 프로토콜과 이를 사용하는 애플리케이션에서 발생할 수 있다. 부채널 공격에 대한 저항성은 애플리케이션과 애플리케이션 프로토콜이 기밀 정보가 의도치 않게 누출되지 않도록 각각 보장하는 데 달려 있다.¶

F.5. 0-RTT에 대한 재전송 공격

재전송 가능한 0-RTT 데이터는 TLS를 사용하는 애플리케이션이 재전송에 안전하도록 특별히 설계되지 않은 경우 여러 보안 위협을 일으킨다 (최소한 멱등성을 의미하지만 많은 경우 상수 시간 응답 같은 더 강한 조건도 필요할 수 있음). 잠재적 공격에는 다음이 포함된다.¶

• 부작용을 일으키는 동작 (예: 물품 구매 또는 송금)을 복제하여 사이트 또는 사용자에게 피해를 주는 경우.¶

• 공격자가 0-RTT 메시지를 저장하고 재전송하여 다른 메시지와의 순서를 바꿀 수 있다 (예: 생성 후에 삭제가 오도록 이동).¶

• 캐싱 같은 부작용으로 발생하는 기존 정보 누출을 증폭한다. 공격자는 관심 있는 리소스를 캐시하지 않은 캐시 노드에 0-RTT 메시지를 재전송한 다음 별도의 연결을 사용해 해당 리소스가 캐시에 추가되었는지 확인하여 0-RTT 메시지 내용에 관한 정보를 알아낼 수 있다. 이는 0-RTT 메시지를 재전송할 수 있는 만큼 서로 다른 캐시 노드에서 반복할 수 있다.¶

데이터를 매우 많이 재전송할 수 있으면 암호화 연산의 속도를 반복 측정하는 등 추가 공격이 가능해진다. 또한 속도 제한 시스템을 과부하시킬 수 있다. 이러한 공격에 대한 자세한 설명은 [Mac17]을 참조한다.¶

궁극적으로 서버는 0-RTT 데이터 복제를 사용하는 공격으로부터 자신을 보호할 책임이 있다. 섹션 8에 설명된 메커니즘은 TLS 계층에서 재전송을 방지하기 위한 것이지만 클라이언트 데이터의 여러 복사본 수신에 대한 완전한 보호를 제공하지는 않는다. 서버가 클라이언트에 관한 정보를 가지고 있지 않은 경우 (예: 상태를 공유하지 않는 다른 클러스터에 있거나 섹션 8.1에 설명된 대로 티켓이 삭제된 경우) TLS 1.3은 1-RTT 핸드셰이크로 대체된다. 이 상황에서 애플리케이션 계층 프로토콜이 데이터를 재전송하면, 공격자는 ClientHello를 원래 클러스터 (데이터를 즉시 처리함)와 다른 클러스터 (1-RTT로 대체하고 애플리케이션 계층 재전송 시 데이터를 처리함)에 모두 전송하여 메시지 복제를 유발할 수 있다. 이 공격의 규모는 클라이언트가 트랜잭션을 재시도하려는 의향에 의해 제한되므로 제한된 양의 복제만 가능하며, 각 복사본은 서버에 새 연결로 나타난다.¶

올바르게 구현하면 섹션 8.1과 섹션 8.2에 설명된 메커니즘은 일관된 상태를 가진 모든 클러스터에서 재전송된 ClientHello와 연관된 0-RTT 데이터가 여러 번 수락되는 것을 방지한다. 단일 티켓에 대해 하나의 클러스터만 0-RTT 사용을 허용하는 서버에서는 특정 ClientHello와 연관된 0-RTT 데이터가 한 번만 수락된다. 그러나 상태가 완전히 일관되지 않으면 복제 창 동안 공격자가 데이터의 여러 복사본을 수락하게 할 수 있다. 클라이언트는 서버 동작의 정확한 세부사항을 알 수 없으므로, 재전송되어도 안전하지 않고 여러 1-RTT 연결에서 재시도할 의향도 없는 메시지를 초기 데이터로 전송해서는 안 된다.¶

애플리케이션 프로토콜은 사용법을 정의하는 프로필 없이 0-RTT 데이터를 사용해서는 안 된다. 해당 프로필은 어떤 메시지나 상호작용이 0-RTT와 함께 사용하기 안전한지, 서버가 0-RTT를 거부하고 1-RTT로 대체하는 상황을 어떻게 처리할지 정의해야 한다.¶

또한 실수로 잘못 사용하는 것을 방지하기 위해 TLS 구현은 애플리케이션이 구체적으로 요청하지 않는 한 0-RTT(전송 또는 수락)를 활성화해서는 안 되며, 서버가 0-RTT 데이터를 거부한 경우 애플리케이션의 지시 없이 자동으로 재전송해서는 안 된다. 서버 측 애플리케이션은 일부 애플리케이션 트래픽 유형에 대해 0-RTT 데이터를 특별하게 처리할 수 있다 (예: 연결 중단, 애플리케이션 계층에서 데이터 재전송 요청, 핸드셰이크 완료까지 처리 지연). 애플리케이션이 이러한 처리를 구현할 수 있도록 TLS 구현은 애플리케이션이 핸드셰이크 완료 여부를 판단할 수 있는 방법을 반드시 제공해야 한다.¶

F.6. PSK 식별자 노출

구현은 유효하지 않은 PSK 바인더에 핸드셰이크 중단으로 응답하므로 공격자가 특정 PSK 식별자가 유효한지 검증할 수 있다. 구체적으로 서버가 외부 PSK 및 인증서 기반 핸드셰이크를 모두 수락하는 경우 유효한 PSK 식별자는 핸드셰이크 실패를 일으키지만, 유효하지 않은 식별자는 건너뛰어 성공적인 인증서 핸드셰이크를 일으킨다. PSK 핸드셰이크만 지원하는 서버는 유효한 PSK 식별자가 없는 경우와 식별자는 있지만 바인더가 유효하지 않은 경우를 동일하게 처리하여 이러한 형태의 공격에 저항할 수 있다.¶

F.7. 프로토콜 버전 간 PSK 공유

TLS 1.3은 PSK를 특정 KDF에 결합하는 보수적인 접근 방식을 사용한다. 반면 TLS 1.2에서는 PSK를 모든 해시 함수 및 TLS 1.2 PRF와 함께 사용할 수 있다. 따라서 TLS 1.2와 TLS 1.3에서 모두 사용하는 모든 PSK는 TLS 1.3에서 하나의 해시에만 사용해야 하며, 사용자가 단일 PSK를 프로비저닝하려는 경우 이는 최적이 아니다. TLS 1.2와 TLS 1.3의 구성은 모두 HMAC을 기반으로 하지만 서로 다르다. 동일한 PSK가 두 버전에서 관련된 출력을 생성할 수 있는 알려진 방법은 없지만 제한적인 분석만 수행되었다. 구현은 TLS 1.3과 TLS 1.2 사이에서 PSK를 재사용하지 않아 교차 프로토콜 관련 출력으로부터 안전성을 보장할 수 있다.¶

F.8. 외부 PSK 및 경로 재지정

TLS의 외부 PSK는 정확히 하나의 클라이언트와 하나의 서버만 알도록 설계되었다. 그러나 [RFC9257]에서 언급한 것처럼 두 개보다 많은 엔터티가 PSK를 공유하는 사용 사례가 있다. 이러한 상황에서는 침해된 그룹 구성원이 다른 모든 구성원을 사칭할 수 있는 예상된 보안 약점 외에도, 악의적인 비구성원이 정직한 그룹 구성원 사이의 핸드셰이크 경로를 재지정하여 의도하지 않은 방식으로 연결할 수 있다 [Selfie]. [RFC9257]은 [RFC9258]에 정의된 외부 PSK 임포터 사용을 포함해 이러한 악의적인 메시지 경로 재지정을 방지하는 외부 PSK 사용 권고사항을 제공한다.¶

F.9. 자체 서명 인증서 또는 원시 공개 키 사용 시 잘못된 바인딩

TLS 1.3을 유용한 신원이 없는 자체 서명 인증서 (DTLS-SRTP [RFC5763]의 경우)나 피어 인증용 원시 공개 키 [RFC7250]와 함께 사용하면 잘못된 바인딩 공격 [MM24]에 취약할 수 있다. 이 위험은 "external_id_hash" 확장 [RFC8844]을 사용하거나, 서버만 인증하는 경우 서버가 "server_name" 확장이 예상 신원과 일치하는지 검증하여 완화할 수 있다.¶

F.10. 정적 RSA에 대한 공격

TLS 1.3은 RSA 키 전송을 사용하지 않으므로 Bleichenbacher 유형 공격 [Blei98]에 직접 취약하지 않지만, TLS 1.3 서버가 이전 TLS 버전의 콘텍스트에서 정적 RSA도 지원하면 TLS 1.3 연결에서 서버를 사칭할 수 있다 [JSS15]. TLS 1.3 구현은 모든 TLS 버전에서 정적 RSA 지원을 비활성화하여 이 공격을 방지할 수 있다. 원칙적으로 구현은 정적 RSA 복호화와 RSA 서명을 위해 서로 다른 keyUsage 비트를 가진 인증서를 분리할 수도 있지만, 이 기법은 digitalSignature 비트가 설정되지 않은 인증서의 키로 생성된 서명을 클라이언트가 거부하는 데 의존하며 많은 클라이언트가 이 제한을 강제하지 않는다.¶