요약

  • RFC 9102는 검증된 TLSA 인증 체인이 하나의 서비스 이름과 포트에 대해 확장 지원 수명을 설정하도록 허용한다. DNS TTL은 여전히 현재 레코드를 지배하며, 더 긴 핀은 서버가 유효한 체인이나 인증된 부정 증거를 계속 제공해야 하는지를 결정한다.
  • TLSA RRset에 대한 유효한 부정 응답, 불안전 위임의 증명, 또는 검증된 수명 0 전환은 핀을 해제할 수 있다. 활성 핀이 증거를 요구하는 동안의 확장 생략은 이와 다른 상황이며 클라이언트가 통신을 중단하게 만들 수 있다.

하나의 핸드셰이크에 숨은 두 가지 약속

클라이언트가 DNS-over-TLS 리졸버에 접속한다고 가정하자. DANE으로 리졸버를 인증하려면 리졸버의 TLSA 레코드와 그것을 증명하는 DNSSEC 경로가 필요하다. 그 경로를 인증 대상인 바로 그 DNS 서비스를 통해 가져오는 것은 어색한 의존 관계를 만든다. RFC 9102는 실험적 우회로를 제공한다. TLS 서버가 TLS 핸드셰이크 안에 DNSSEC 인증 체인을 실어 보낼 수 있는 것이다.

응답은 증거와ExtSupportLifetime이라는 숫자를 함께 담는다. 증거는 현재의 질문에 답한다: DNSSEC 검증된 TLSA RRset이 이 SNI 이름과 포트에 대한 인증서 체인과 일치하는가? 그 숫자는 다른, 미래 지향적 질문에 답한다: 이 서버, 또는 이 서비스 클러스터는 몇 시간 동안 확장 지원을 약속하는가?

Shumon Huque는 Viktor Dukhovni, Willem Toorop, Paul Wouters, Melinda Shore와 함께 RFC 9102의 다섯 저자 중 한 명이다. 이 RFC는 원래 아이디어를 Adam Langley에게 돌린다. Huque의 현재 IETF 프로필과 그의 자기 소개는 Salesforce, Verisign, 펜실베이니아 대학교에서의 역할 이후 DNS 인프라, 네트워킹, 보안 프로토콜에 대한 작업을 설명한다. 이 이력은 그를 이 메커니즘으로 들어가는 유용한 통로로 만들지만, 집단적 실험 RFC를 그의 개인 소유로 만들지는 않는다.

두 약속의 구분이 이 글의 핵심이다. TLSA RRset에는 TTL이 있다. 그 DNSSEC 서명에는 유효 시작 시각과 만료 시각이 있다. 서버는 이 구성요소들이 바뀔 때 체인을 다시 만들어야 한다. 확장 지원 수명은 이 시계들과 명시적으로 독립적이다. 일주일짜리 지원 약속이 5분짜리 TLSA 레코드를 일주일짜리 자격 증명으로 늘려주지는 않는다.

핀은 긍정적 검증 이후에만 시작된다

클라이언트는 확장 필드를 보았다는 이유만으로 안전하게 기능을 고정할 수 없다. RFC 9102는 응답이 서버 인증서 체인과 일치하는 유효한 TLSA 인증 체인을 담고 있을 때만 0이 아닌 값의 사용을 허용한다. 완료된 핸드셰이크는 DANE 인증을 통과해야 한다. 구문상 올바른 메시지, 관례적 PKIX 성공, 또는 검증되지 않은 DNS 레코드 집합은 동일한 상태를 만들 수 없다.

핀에는 범위가 있다. 클라이언트가 요청에 TCP 포트를 보내면, 서버는 그 포트와 클라이언트의 SNI 호스트명으로 TLSA 이름을 만든다. 이 인밴드 방식에서 서버는 SNI 이름 뒤의 CNAME을 확장해서는 안 된다. 그 결과로 생기는 기억은 이름과 포트로 식별되는 서비스 인스턴스에 속하지, 한 IP 주소의 모든 이름에도, 공유 호스트의 모든 테넌트에도 속하지 않는다.

클라이언트는 수명에 대해 일정한 통제권을 유지한다. 서버가 광고한 수명을 로컬 최대값으로 줄일 수 있다. RFC는 침해된 서버가 최대 7년치를 광고하는 드물지만 심각한 경우를 언급한다. 그러나 지나치게 짧은 상한은 다운그레이드 저항도 약화시킨다. 따라서 이 값은 서버의 명령도, 장식적 힌트도 아니며, 클라이언트 정책으로 경계가 정해진 제공된 약속이다.

짧은 시계와 긴 시계

클라이언트가 만료되지 않은 검증된 TLSA RRset을 갖고 있으면, 이후 접속에서 그 레코드를 재사용하고 확장을 생략할 수 있다. 재사용은 수신한 TTL에서 끝난다. TLSA 캐시가 만료되었는데 확장 핀이 여전히 활성 상태라면, 클라이언트는 다시 현재 증거를 얻어야 한다. 보통은 확장을 요청하거나, 다른 DNSSEC 유효 방식을 통해서이다.

이로써 두 개의 시계가 생긴다. 짧은 시계는 현재 TLSA 연관관계의 신선함을 보호한다. 긴 시계는 증거 채널의 연속성을 보호한다. 둘은 어느 쪽이든 먼저 만료될 수 있다. 핀만 모니터링하면 오래된 DNS 자료를 놓칠 수 있고, TTL만 모니터링하면 서비스의 응답 지속 의무를 놓칠 수 있다.

TLS 세션 재개는 세 번째 상태를 더한다. RFC 9102는 재개된 세션에는dnssec_chain이 없으며, TLS 1.3에서는 체인이 붙을 인증서 메시지도 생략된다고 언급한다. 확장이 없는 모든 재개 핸드셰이크를 다운그레이드로 세는 운영자는 허위 경보를 만들어낸다. 유용한 기록은 전체 핸드셰이크와 재개 핸드셰이크의 구분, 캐시된 TLSA 만료, 활성 핀 만료, 실제 사용된 증거를 남긴다.

부정 증거는 누락된 증거가 아니다

가장 중대한 분기는 도메인이 더 이상 TLSA 레코드를 게시하지 않을 때 발생한다. 지원하는 서버는 요청된 TLSA 이름에 대한 인증된 부정(denial)을 증명하는 DNSSEC 체인을 돌려줄 수 있다. 검증되면 그 부정 응답은 확장 핀을 해제할 수 있다. 불안전 위임의 증명도 그렇게 할 수 있다. 이후 로컬 정책이 PKIX로 계속할지 연결을 닫을지 결정한다.

침묵은 다른 의미를 갖는다. 클라이언트가 활성 핀을 갖고, 만료되지 않은 캐시된 TLSA RRset이 없고, 필요한 확장을 받지 못했다면, 밴드 외부에서 유효한 TLSA 데이터나 유효한 부정 증거를 얻을 때까지 통신을 중단하거나 지연해야 한다. 어느 쪽도 얻지 못하면 TLS 시도가 끝난다. 생략을 부재로 다루면 핀이 막도록 설계된 다운그레이드 경로를 재현하게 된다: 공개 신뢰 인증서를 가진 불법 서버가 DANE 자료를 그냥 내보내지 않을 수 있기 때문이다.

그래서 RFC 9102는 확장 요구가 TLSA, 나아가 DNSSEC를 영원히 요구하는 것과 같지 않다고 말한다. 영역 운영자는 TLSA 레코드나 DS 레코드를 제거할 수 있다. 핀이 살아 있는 동안 남는 것은 서버가 검증 가능한 상태를 돌려줄 의무다. 오래된 긍정 답변은 사라질 수 있고, 그 자리는 인증된 전환이 대신해야 한다.

퇴역은 0, 그리고 시간이 필요하다

확장을 비활성화하려는 운영자는 단순히 제거할 수 없다. RFC 9102는 단계적 퇴출을 정한다. 먼저 DANE 인증 핸드셰이크에서 0인ExtSupportLifetime을 광고하고, 그다음 이전에 광고된 모든 핀이 만료될 수 있을 때까지 기다렸다가, 그 후에야 확장 제공을 멈춘다. TLSA나 DNSSEC은 더 일찍 제거할 수 있지만, 활성 핀을 가진 클라이언트는 여전히 인증된 부정 응답을 필요로 한다.

호스팅 서비스에서 이 일정은 여러 조직에 걸친다. 도메인 소유자는 관련 DNS 데이터를 통제하고 제공자를 옮기고 싶어할 수 있고, 제공자는 인증서, TLS 엔드포인트, 인밴드 체인 생성을 통제할 수 있다. 그래서 RFC는 0이 아닌 수명을 상호 합의로만 사용하도록 권고한다. 클러스터 전체 약속은 모든 서빙 노드가 이행할 수 있을 때만 운영적으로 유효하다.

신뢰 역시 서버의 단언 바깥에 남는다. 클라이언트는 구성된 DNSSEC 신뢰 앵커로부터 체인을 검증하고, RRSIG 검사를 위해 충분히 정확한 시각이 필요하며, 앵커 로테이션을 통해 그 앵커를 유지해야 한다. 레코드를 핸드셰이크 안으로 옮기는 것은 밴드 외부 조회를 없앨 뿐, 엔드포인트가 자신을 신뢰의 뿌리로 임명하게 해주지 않는다.

RFC 9102는 자신의 지위에 대해 솔직하다. 핀 방식은 TLS 워킹 그룹에서 배포 가능성 우려를 낳았고, 이 문서는 그 우려를 연구하려는 실험으로 메커니즘을 위치시킨다. 여기서 검토한 공개 자료는 주요 클라이언트나 서버에서 현재의 채택을 입증하지 않는다. 지속적 기여는 더 좁다: 긍정적 단언, 인증된 부정 단언, 그리고 답변의 부재를 하나의 비트로 축소할 수 없는 상태 기계를 명시한 것이다.

출처