| RFC 9852 | TLS를 사용하는 새 프로토콜은 TLS를 요구해야 한다 | 2026년 7월 |
| Salz & Aviram | 최선의 현행 관행 | [페이지] |
TLS 1.3은 널리 사용되고 있으며, 포괄적인 보안 증명을 거쳤고, TLS 1.2의 보안 및 개인정보 보호 결함을 모두 개선한다. 따라서 TLS를 사용하는 새 프로토콜은 TLS 1.3을 요구해야 한다. DTLS 1.3은 널리 제공되거나 배포되어 있지 않으므로, 이 지침은 DTLS(어떤 DTLS 버전에도)에는 적용되지 않으며 TLS에만 적용된다.¶
이 문서는 RFC 9325를 갱신한다. 이 문서는 갱신의 근거로서 포스트 양자 암호와 TLS 1.3의 보안 및 개인정보 보호 개선 사항을 논의한다.¶
이 메모는 인터넷 최선의 현행 관행을 문서화한다.¶
이 문서는 인터넷 엔지니어링 태스크 포스 (IETF)의 산출물이다. 이 문서는 IETF 커뮤니티의 합의를 나타낸다. 이 문서는 공개 검토를 거쳤으며 인터넷 엔지니어링 운영 그룹 (IESG)의 발행 승인을 받았다. BCP에 관한 자세한 정보는 RFC 7841의 제2절에서 확인할 수 있다.¶
이 문서의 현재 상태, 정오표 및 이 문서에 대한 의견을 제공하는 방법에 관한 정보는 https://www.rfc-editor.org/info/rfc9852에서 확인할 수 있다.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
이 문서는 TLS를 사용하는 새 프로토콜이 TLS 1.3을 사용할 수 있다고 가정하고 그 사용을 요구해야 한다고 명시한다. DTLS 1.3은 널리 제공되거나 배포되어 있지 않으므로, 이 지침은 DTLS(어떤 DTLS 버전에도)에는 적용되지 않으며 TLS에만 적용된다.¶
TLS 1.3 [TLS13]은 널리 사용되고 있으며 TLS 1.2에서 알려진 대부분의 결함을 해결한다. 예를 들어 트래픽의 더 많은 부분을 암호화하여 외부인이 읽을 수 없도록 하고, 현재 취약한 것으로 간주되는 대부분의 암호학적 기본 요소를 제거한다. 중요한 점은 이 프로토콜이 포괄적인 보안 증명을 거쳤으며 추가적인 구성 없이도 뛰어난 보안을 제공해야 한다는 것이다.¶
TLS 1.2 [TLS12]는 사용 중이며 우수한 보안 속성을 제공하도록 구성할 수 있다. 그러나 TLS 1.2에는 제6절에 설명된 것과 같은 여러 결함이 있다. 이러한 결함을 해결하려면 일반적으로 맞춤형 구성이 필요하다.¶
이 문서는 [RFC9325]를 갱신한다. 이 문서는 갱신의 근거로서 포스트 양자 암호와 TLS 1.3의 보안 및 개인정보 보호 개선 사항을 논의한다. 제5절을 참조한다.¶
이 문서에서 핵심 단어 "반드시", "해서는 안 된다", "요구된다", "해야 한다", "해서는 안 된다", "하는 것이 좋다", "하지 않는 것이 좋다", "권고된다", "권고되지 않는다", "할 수 있다" 및 "선택 사항이다"는 여기에 표시된 것처럼 모두 대문자로 나타나는 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석해야 한다.¶
암호학적으로 유의미한 양자 컴퓨터(CRQC)를 사용할 수 있게 되면 TLS 트래픽에 막대한 영향을 미칠 것이다(예: [RFC9958]의 제3절 참조). 이를 완화하기 위해 TLS 애플리케이션은 포스트 양자 암호(PQC) [PQC]로 마이그레이션해야 한다. 애플리케이션에 PQC가 필요한 시점이나 CRQC가 애플리케이션이 방어해야 하는 위협이 되는 시점에 관한 상세한 고려 사항은 이 문서의 범위를 벗어난다.¶
TLS 워킹 그룹이 TLS 1.3 이상에 노력을 집중하고 있으며 TLS 1.2는 지원되지 않는다는 점에 유의해야 한다([TLS12FROZEN] 참조). 이것은 새 프로토콜이 TLS의 기본값으로 TLS 1.3을 요구해야 하는 또 하나의 이유이다. TLS 1.3에서는 PQC가 활발하게 표준화되고 있으므로 새 애플리케이션에 PQC를 사용할 수 있는 선택권을 제공한다.¶
TLS를 사용하는 모든 새 프로토콜은 TLS 1.3을 기본값으로 반드시 지정해야 한다. 예를 들어 QUIC [QUICTLS]은 TLS 1.3을 요구하며, 이전 버전이 사용되는 경우 엔드포인트가 연결을 반드시 종료해야 한다고 명시한다.¶
배포 고려 사항이 문제가 되는 경우, 프로토콜은 TLS 1.2를 기본값이 아닌 추가 옵션으로 지정할 수 있다. 반대 사례로, DNS over TLS 사용 프로필 [DNSTLS]은 TLS 1.2를 기본값으로 지정하면서 TLS 1.3도 허용한다. TLS 1.2 지원을 선택하는 최신 명세에서는 이러한 우선순위를 반대로 해야 한다.¶
초기 TLS 핸드셰이크를 통해 클라이언트는 지원하는 TLS 버전을 지정할 수 있으며, 서버는 자신도 지원하는 버전 중 가장 높은 버전을 선택하도록 되어 있다. 이를 "TLS 버전 협상"이라고 하며, 프로토콜 및 협상에 관한 자세한 내용은 [TLS13]의 제4.2.1절과 [TLS12]의 부록 E에서 논의한다. 많은 TLS 라이브러리는 최저 버전이나 최고 버전만 지정하는 열린 구간을 포함하여 애플리케이션이 원하는 버전 범위를 지정할 수 있는 방법을 제공한다.¶
애플리케이션이 TLS 버전 협상을 지원하는 TLS 구현을 사용하고 해당 TLS 구현이 지원되는 가장 높은 버전을 사용한다는 것을 알고 있다면, 클라이언트는 원하는 최저 버전만 지정하는 것이 좋다. 이는 위 문단에 설명된 상황에 따라 TLS 1.3 또는 TLS 1.2여야 한다.¶
[RFC9325]는 TLS와, 이 문서와 달리 DTLS도 사용하는 배포된 서비스의 보안을 보장하기 위한 권고 사항을 제공한다. [RFC9325]는 TLS 1.3을 "널리 제공되는" 것으로 설명하며, 해당 문서가 발행된 이후 TLS 1.3으로의 전환은 더욱 확대되었다. 따라서 이 문서는 [RFC9325]의 제3.1.1절에 있는 권고 사항을 두 가지 변경한다.¶
해당 절에서는 TLS 1.3을 지원하는 것이 좋다고 명시하지만, 이 문서는 TLS를 사용하는 새 프로토콜이 TLS 1.3을 반드시 지원하도록 요구한다.¶
해당 절에서는 TLS 1.2를 반드시 지원해야 한다고 명시하지만, 이 문서는 위에서 설명한 대로 TLS 1.2를 지원할 수 있다고 명시한다.¶
다시 말하지만, 이러한 변경 사항은 TLS에만 적용되며 DTLS에는 적용되지 않는다.¶
TLS 1.2는 시간이 지남에 따라 상당히 취약해진 여러 암호학적 기본 요소와 설계 선택을 사용하여 명세되었다. 이 절의 목적은 프로토콜에 영향을 준 대표적인 문제 몇 가지를 간략히 살펴보는 것이다. 그러나 TLS 1.2도 안전하게 구성할 수 있다는 점에 유의해야 한다. 다만 현대적인 후속 버전인 TLS 1.3을 사용하는 것보다 안전하게 구성하기가 훨씬 더 어려울 뿐이다. TLS 1.2의 안전한 배포에 관한 더 자세한 지침은 [RFC9325]를 참조한다.¶
첫째, 확장을 사용하지 않는 TLS 1.2는 재협상 공격([RENEG1] 및 [RENEG2] 참조)과 삼중 핸드셰이크 공격([TRIPLESHAKE] 참조)에 취약하다. 대체로 이러한 공격은 재협상에 대한 프로토콜의 지원을 악용하여 공격자가 선택한 접두부를 평문 스트림에 삽입한다. 이는 일반적으로 실제 환경에서 치명적인 위협이다(예: 공격자가 웹 환경에서 비밀 쿠키를 획득할 수 있게 한다). 위 문제를 고려하여 [RFC5746]은 이러한 공격 범주를 방지하는 확장을 명시한다. TLS 1.2를 안전하게 배포하려면 재협상을 완전히 비활성화하거나 이 확장을 사용해야 한다. 또한 클라이언트는 연결 중 서버가 인증서를 재협상하도록 허용해서는 안 된다.¶
둘째, TLS 1.2에 명시된 원래의 키 교환 방식인 RSA 키 교환과 유한체 Diffie-Hellman에는 여러 취약점이 있다. 프로토콜을 안전하게 배포하려면 이러한 키 교환 방식의 대부분을 비활성화해야 한다. 자세한 내용은 [RFC10015]를 참조한다.¶
셋째, TLS 1.2에서 널리 사용되는 대칭 암호인 RC4와 암호 블록 체인(CBC) 암호 스위트에는 여러 취약점이 있다. RC4의 키 스트림에는 악용 가능한 편향이 있다. [RFC7465]를 참조한다. CBC 암호 스위트는 오랫동안 취약점의 원인이 되어 왔다. 이러한 암호 스위트를 단순하게 구현하면 본질적으로 Lucky13 타이밍 공격 [LUCKY13]에 취약하다. 암호 스위트를 상수 시간으로 구현하려는 최초의 시도는 훨씬 더 심각한 취약점 [LUCKY13FIX]을 초래했다. CBC 암호 스위트의 또 다른 취약점 사례와 유사 연구에 대한 조사는 [CBCSCANNING]을 참조한다.¶
또한 TLS 1.2는 TLS 1.3에는 영향을 미치지 않는 여러 다른 공격의 영향을 받았다. BEAST [BEAST], Logjam [WEAKDH], FREAK [FREAK] 및 SLOTH [SLOTH]이다.¶
마지막으로 TLS 1.2의 애플리케이션 계층 트래픽은 항상 암호화되지만, 핸드셰이크 메시지 내용의 대부분은 암호화되지 않는다. 따라서 제공되는 개인정보 보호 수준은 최적이 아니다. 이는 구성으로 해결할 수 없는 프로토콜 문제이다.¶
이 문서에는 IANA 조치가 없다.¶