요약

  • TLS는 넉넉한 레코드 상한으로 시작했고, 이후 클라이언트가 선택하는 더 작은 프래그먼트를 제안해 양방향에 같은 크기를 적용했습니다. 이 대칭성은 보호된 레코드의 수신이 종종 더 무거운 메모리 부담이라는 사실을 가려왔습니다.
  • RFC 8449는 레코드 용량을 방향성 선언으로 바꾸었습니다. 각 엔드포인트가 자신이 수신할 수 있는 양을 밝히고, 상대방은 그에 맞게 데이터를 프래그먼트화하며, 초과 레코드는 로컬에서 실패하고 네트워크 경로나 애플리케이션 메시지에 대한 주장으로 바뀌지 않습니다.

기계는 안전하게 수신할 수 없는 것을 보낼 수 있었다

작은 작업 버퍼와 하드웨어 암호화기를 가진 센서를 생각해 봅시다. 전송 시에는 평문을 암호화기에 넣고 암호문을 점진적으로 회선에 내보낼 수 있습니다. 그러나 수신 시에는 다른 규칙이 적용됩니다. 보호된 평문을 애플리케이션에 넘기기 전에, 레코드의 진위를 검증할 만큼 충분한 데이터를 이미 확보해야 합니다. 위조된 앞부분이 나머지가 도착하지 않았다는 이유만으로 애플리케이션 데이터가 되어서는 안 됩니다.

이것은 겉보기에 단순한 수치인 레코드 크기를 책임의 배분으로 만듭니다. 송신자는 하나의 보호 단위에 얼마나 많은 애플리케이션 또는 핸드셰이크 데이터를 넣을지 선택하고, 수신자는 이를 수용하고 검증하기 위한 원자적 메모리 비용을 지불합니다. 프로토콜상 동등한 역할이 동등한 하드웨어를 의미하지는 않으며, 큰 레코드를 만들 수 있다는 사실이 반대 방향으로 오는 큰 레코드를 담을 수 있다는 증거도 아닙니다.

RFC 8449는 이 비대칭을 명시적으로 만들었습니다. 이 문서의 결정적 역사적 기여는 단순히 더 작은 숫자가 아니라, 어떤 쪽의 숫자가 중요한지를 바꾼 것입니다.

16 키비바이트는 상한이지 메모리 약속이 아니었다

TLS 1.2는 상위 계층 데이터를 임의의 블록으로 받아들여 2^14바이트를 넘지 않는TLSPlaintext레코드에 담았습니다. 레코드 계층은 하나의 상위 계층 메시지를 여러 레코드로 나누거나, 같은 유형의 여러 메시지를 하나의 레코드로 합칠 수 있었습니다. 따라서 TLS 레코드 경계는 애플리케이션 메시지 경계도 TCP 세그먼트 경계도 아니었습니다.

16 KiB 평문 상한은 범용 시스템이 레코드 헤더와 암호화 작업을 분산할 여지를 주었습니다. 동시에 최악의 수신 부담도 만들었습니다. 압축과 보호는 회선상의 객체를 더 크게 만들 수 있습니다. RAM이 적은 엔드포인트의 경우, 최대 보호 레코드를 담을 공간을 확보하는 일이 설계 전체를 지배할 수 있었습니다.

이 상한이 모든 송신자가 꽉 찬 레코드를 사용해야 한다는 뜻은 아니었습니다. 다른 메커니즘이 합의를 좁히지 않는 한, 모든 준수하는 상대방이 그에 대비해야 한다는 뜻이었습니다.

첫 번째 해답은 클라이언트가 양방향을 대신 정하는 것이었다

2006년 TLS 확장 명세와 그 후속인RFC 6066은max_fragment_length를 도입했습니다. 클라이언트는 512, 1024, 2048, 4096바이트 중 하나의 평문 크기를 요청할 수 있었습니다. 서버가 수락하면 정확히 그 값을 되돌려 주고, 양쪽 모두 즉시 애플리케이션과 핸드셰이크 데이터를 이 한도 안으로 프래그먼트화했습니다. 이 선택은 세션 내내 유지되었고, 이 설계에서는 재개 시에도 유지되었습니다.

이것은 유용했습니다. IETF의 이후 제약 기기 프로필인RFC 7925는 이 확장을, 클라이언트가 16 KiB 레코드를 그대로 받아들이는 대신 자신의 수신 버퍼 요구를 낮추는 방법으로 설명했습니다. 숨겨진 구현 한계를 협상된 프로토콜 동작으로 바꾼 것입니다.

그러나 이 협상의 구조는 원래 그림에 맞지 않는 당사자들에게 불리했습니다. 유능한 클라이언트는 이 확장을 통해 일반적인 16 KiB 상한을 광고할 수 없었습니다. 가장 큰 코드포인트조차 4096이었기 때문입니다. 이를 제안하면 서버가 도움을 필요로 하지 않을 때조차 처리량이 떨어질 수 있었습니다. 레코드가 늘어날수록 프레이밍과 보호 오버헤드가 반복되고 더 많은 처리가 필요해졌습니다. 더 중요한 것은, 서버가 클라이언트의 값만 수락할 수 있었다는 점입니다. 제약된 서버가 독립적으로 “더 적게 보내라”고 말할 방법이 없었고, 제약된 클라이언트는 자신이 받는 트래픽과 보내는 트래픽 모두에 같은 작은 크기를 강제했습니다.

하나의 공유 설정은 중립적으로 보였습니다. 실제로는 먼저 접속을 시작하는 쪽에 유일한 제안 권을 주고, 서로 다른 두 수신 기계를 하나의 용량 등급으로 취급했습니다.

RFC 8449는 이 숫자를 안쪽으로 향하게 했다

record_size_limit확장은 이 의미를 뒤집었습니다. 그 값은 광고하는 엔드포인트가 수신할 의사가 있는 가장 큰 보호 레코드 평문입니다. 상대방은 이 엔드포인트로 향하는 레코드를 이 값 안에 맞춰야 합니다. 광고자는 반대 방향으로 더 큰 레코드를 보낼 수 있으며, 단 상대방의 선언과 해당 TLS 버전의 일반 상한을 존중해야 합니다.

따라서 하나의 연결에서 두 값은 서로 다를 수 있습니다. 작은 기기는 클라우드 서비스에 작은 인바운드 레코드를 요청하면서, 서비스가 수용할 수 있는 더 큰 레코드를 보낼 수 있습니다. 제약된 서버는 클라이언트에 수신 제약이 없더라도 마침내 자기 한도를 선언할 수 있습니다. 완전한 능력을 갖춘 엔드포인트도 확장을 광고하는 것이 권장됩니다. 그래야 상대방이 실용적인 선언을 할 수 있기 때문입니다.

이것은 정확한 결과를 가진 로컬 권한입니다. 이 선언은 더 적은 메모리를 할당할 허락을 구하는 것이 아닙니다. 엔드포인트는 이미 자신의 메모리를 통제합니다. 상대방에게 그 사실과 호환되는 방식으로 보호 레코드를 만들라고 알려주는 것입니다. TLS 상대방이 광고된 한도를 넘는 보호 레코드를 보내면, 수신자는 치명적인record_overflow로 연결을 끝내야 합니다. DTLS의 경우 수신자는 대신 초과 레코드를 폐기할 수 있습니다.

하한도 명시적입니다. 64 미만의 값은 불법입니다. 이 하한은 64바이트 레코드가 효율적이라는 권고가 아닙니다. RFC 8449는 아주 작은 레코드가 작업량을 늘리고 처리량을 낮추며 서비스 거부 노출을 키울 수 있다고 경고합니다.

계산 대상은 회선상의 모든 바이트가 아니라 보호된 평문이다

이 숫자는 버전별 계산 규칙을 가집니다. TLS 1.2 이하에서는 압축과 암호화에 들어가는 데이터를 대상으로 하며, 암호화 패딩은 이 계산에서 제외됩니다. TLS 1.3에서는TLSInnerPlaintext전체, 즉 콘텐츠, 내부 콘텐츠 유형 바이트, 그리고 TLS 1.3 레코드 패딩을 모두 대상으로 합니다. 따라서 선언된 TLS 1.3 한도에는 보호 콘텐츠의 식별이나 은폐를 위해 존재하는 바이트도 포함되며, 애플리케이션 페이로드만 포함되는 것이 아닙니다.

TLS 1.3은 트래픽 길이를 은폐하기 위해 암호화된 레코드에 패딩을 넣을 수 있지만, 패딩으로 수신자의 상한을 회피할 수는 없습니다.record_size_limit가 상한을 줄이면 콘텐츠 유형과 패딩도 그 안에 들어가야 합니다. 개인정보 보호 정책은 애플리케이션 콘텐츠와 동일한 인바운드 용량을 소비합니다.

보호되지 않은 핸드셰이크 레코드는 이 확장의 대상이 아닙니다. 한도는 재개 또는 레거시 재협상 시 다시 협상되며, 레코드를 보호하는 키를 만든 핸드셰이크를 따릅니다. 오래된 한도는 신원이나 티켓의 영구 속성이 아닙니다.

이것은 경로 측정이 아니다

레코드 용량은 Path MTU와 혼동하기 쉽습니다. 둘 다 송신자가 더 작은 단위를 내보내게 만들 수 있기 때문입니다. RFC 8449는 이 둘을 명확히 분리합니다. 레코드 한도는 엔드포인트의 처리 제약에서 오며 핸드셰이크 동안 고정됩니다. PMTU는 경로에서 오고, 패킷 운반을 제약하며, 연결이 진행되는 동안 바뀔 수 있습니다. 여러 개의 작은 DTLS 레코드는 여전히 하나의 UDP 데이터그램에 담길 수 있습니다.

이 확장은 HTTP 응답, 인증서 체인 또는 애플리케이션 메시지를 제한하지도 않습니다. 이러한 객체는 여러 레코드에 걸칠 수 있습니다. 이 확장은 대역폭, 처리 속도, 코드 공간, 배터리 수명 또는 모든 종류의 메모리 실패로부터의 보호를 약속하지 않습니다. 다루는 문제는 하나로 한정됩니다. 수신자가 하나의 단위로 처리하기로 합의한 보호 레코드 평문의 크기입니다.

바로 이 좁음이 메커니즘을 오래 지속 가능하게 만듭니다. IANA는 이제 확장 28인record_size_limit를 TLS 1.3 ClientHello 및 EncryptedExtensions 컨텍스트에서 Recommended로 등록하고 있으며, 확장 1인max_fragment_length는 Recommended가 아닙니다. 레지스트리는 표준화된 선택을 기록할 뿐, 특정 제품이 이를 구현했거나 협상된 값이 운영상 현명하다는 것을 증명하지 않습니다.

더 깊은 역사는 프로토콜 대칭에 대한 교정입니다. TLS는 양쪽 엔드포인트가 동등해질 필요가 없었습니다. 각 엔드포인트가 자기만이 알 수 있는 하나의 경계를 서술하고, 상대방이 그 비용이 착지하는 방향에서 이 선언에 따라 행동할 필요가 있었습니다.

출처와 근거 한계

이 글은RFC 4366,RFC 5246,RFC 6066,RFC 7925,RFC 8446,RFC 8449와IANA TLS ExtensionType 레지스트리를 사용했습니다. 이 문서들은 프로토콜 설계와 등록 상태를 확립할 뿐, 현재 배포 점유율, 기기 메모리 프로파일 또는 특정 워크로드에 적합한 레코드 크기를 제시하지 않습니다.