2021년 8월 11일 RFC 9102 "TLS DNSSEC Chain Extension"이 발행되었습니다. TLS 서버를 DNS 기반 개체 인증(DANE)으로 인증할 때 필요한 DNSSEC 검증 레코드 전체를 TLS 연결 안에서(in-band) 클라이언트에 전달하는 확장을 정의합니다. 클라이언트가 따로 DNS 조회를 하지 않아도 됩니다. 이 문서는 인터넷 표준 트랙이 아닌 실험적(Experimental) 문서입니다.
무엇이 발표되었나
- 동작 방식: TLS 클라이언트가 이 확장으로 요청하면, 확장을 지원하는 서버가 필요한 DNS 질의를 직접 수행합니다. 서버는 자신의 DANE TLSA 레코드 집합(RRset)에 대한 DNSSEC 인증 체인(authentication chain)을 만들어 돌려줍니다. 클라이언트는 미리 설정된 DNSSEC 신뢰 앵커(trust anchor)로 이 체인을 검증합니다. 서버는 보통 캐시해 둔 체인을 쓰지만, 주기적으로 다시 만들어야 합니다(본문 4절).
- 부재 증명: TLSA 레코드가 없으면 검증할 수 있는 존재 부정 증명(authenticated denial of existence)을 대신 전달합니다. 이 증명이 있어야 클라이언트가 로컬 정책이 허용하는 경우 PKIX(WebPKI) 기반 인증으로 안전하게 넘어갈 수 있습니다. 또 DANE이 적용된 인증된 기회적 TLS(opportunistic TLS)가 인증 없는 기회적 TLS로 격하(downgrade)되는 것도 막습니다.
- 지원 대상: DANE 규격에 따라 X.509 인증서와 원시 공개키(raw public key)를 모두 지원합니다. 원시 공개키를 쓸 때는 반환된 TLSA RRset으로 서버가 자신의 DNS 이름을 확인시켜 주므로 미지 키 공유(UKS) 공격도 완화됩니다.
- 문서 성격: IETF 밖에서 개발된 확장입니다. 구현 지침과 구현 간 상호운용성을 위해 RFC Editor가 독립 경로(Independent stream)로 발행했습니다. RFC Editor는 이 문서의 구현·배포 가치에 대해 어떤 입장도 밝히지 않는다고 명시했습니다. 저자는 V. Dukhovni, S. Huque, W. Toorop, P. Wouters, M. Shore입니다.
영향 범위
원문은 이 확장이 특히 잘 맞는 용도로 DNS over TLS(DoT, RFC 7858)를 꼽습니다. DoT 리졸버를 DANE으로 인증하려 할 때는 필요한 DNS 조회 자체를 아직 할 수 없는 경우가 있기 때문입니다. 실제로 RFC 8310 8.2.2절은 DoT 인증 방법 중 하나로 이 방식을 규정하고 있습니다. 원문은 다른 TLS 서비스에도 이 확장을 시험해 보라고 권합니다. 이렇게 하면 동작하는 DNSSEC 리졸버가 없는 단말에서도 DANE 인증을 쓸 수 있습니다.
TLS 워킹그룹에서는 확장 고정(pinning) 기법(본문 7절)이 배포를 어렵게 만들 수 있다는 우려가 나왔습니다. 이 실험의 목적은 실제 배포에서 이 문제가 얼마나 복잡한지 살펴보는 것입니다. 실험이 성공하면 그 결과를 반영한 개정 문서가 표준 트랙 승인을 받을 것으로 예상된다고 원문은 밝힙니다.
운영자가 할 일
실험적 문서이므로 당장 바꿔야 할 설정은 없습니다. 다만 DoT 서비스를 운영하거나 TLS 서비스에 DANE(TLSA 레코드)을 적용했거나 적용을 검토 중이라면 다음을 참고하시기 바랍니다.
- 이 확장을 지원하는 서버는 인증 체인을 만들기 위해 직접 DNS 질의를 수행합니다. 따라서 서버 쪽의 DNS 해석 경로와 DNSSEC 서명 상태가 정상인지가 중요합니다.
- TLSA 레코드가 없을 때 쓰이는 존재 부정 증명도 DNSSEC 검증을 통과해야 합니다. 영역의 DNSSEC 서명과 부재 증명 레코드가 올바르게 관리되고 있는지 점검해 두는 것이 좋습니다.
- 확장 고정(pinning) 관련 내용은 본문 7절을 확인하시기 바랍니다.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.