요약
- RFC 3008은 암호학적 유효성을 DNSSEC 수용의 한 부분으로만 만들었다. 데이터 서명이 리졸버의 실질적 근거로 취급되려면 올바른 필드와 일치하는 영역 키도 필요했다.
- 호스트 키와 사용자 키는 SIG(0) 트랜잭션 인증 역할을 유지했지만, 공개 데이터에는 영역 키가 서명했다. 이로써 변경을 제안할 권한과 영역의 내용을 증명할 권위가 분리되었다.
서명은 시간 안에서 완벽하게 계산되어 올바른 바이트에 부착되어 있어도 여전히 효력을 인정받지 못할 수 있었다. 2000년 11월에Domain Name System Security (DNSSEC) Signing Authority로 발표된RFC 3008의 출발점이 바로 이것이다. 이 문서는 새로운 서명 알고리즘을 만들지 않았다. 리졸버가 어떤 검증된 서명을 DNSSEC의 공개 증거 사슬에 속하는 것으로 판단할지에 대한 규칙을 개정했다.
이 구분은 “실질적(material)” 서명과 “비실질적(immaterial)” 서명이라는 언어로 표현되었다. 데이터 SIG는 보통 하나의 RRset을 커버하며 그 출처와 무결성을 보일 수 있었다. 그러나 SIG는 대신 응용이 정의한 역할을 맡거나, RRset과의 관계가 없거나, SIG(0)로 DNS 메시지를 보호할 수도 있었다. 그런 서명들은 진짜일 수 있으면서도 DNSSEC 검증에 실질적이지는 않았다. 이진 암호학적 답과—who가 영역 데이터를 대변할 수 있는가라는 제도적 답—은 서로 분리되어 있었다.
이 구분은RFC 2535의 모호성을 바로잡았다. 이전 DNS 보안 모델은 일부 상황에서 영역 키, 호스트 키, 사용자 키 모두가 데이터에 서명할 수 있도록 했다. 한 가지 동기는 동적 업데이트였다. 영역의 가장 민감한 개인 키를 오프라인에 둔 채 호스트가 자신이 도입한 데이터에 서명할 수 있도록 하는 것이었다. 이 구조는 서명 권위를 분산시키고 노출을 줄이는 것처럼 보였다.
RFC 3008은 약속된 오프라인 경계가 전체 시스템에서 살아남지 못했다고 논증했다.RFC 3007의 업데이트 경로가 보여주듯, 보안 동적 업데이트는 여전히 SOA와 NXT 집합을 위한 온라인 영역 서명을 필요로 했다. 온라인 영역 키가 이미 존재해야 하고 들어오는 데이터에 서명할 수 있다면, 모든 호스트나 사용자 서명을 실질적인 공개 근거로 만드는 것은 의도했던 “온라인 영역 키 부재”를 더 이상 가져다주지 못했다. 다만 모든 리졸버에게 더 복잡한 권위 판단을 남겼다.
따라서 개정판은 보안 영역의 데이터가 표준 정책 아래 영역 키로 서명되어야 한다고 요구했다. 리졸버는 명시적인 로컬 정책이 달리 지시하지 않는 한, 실질적 데이터 서명에 대해 비영역 키를 무시해야 했다. 이 변경은 의도적으로 제한적이었다. 유연한 서명자 그래프를, 검증 사슬이 DNS 이름의 라벨 깊이로 경계 지어지고 그 권위를 영역 구조에서 읽을 수 있는 기준선으로 대체한 것이다.
“영역 키”라는 표지는 나머지 검증을 우회하는 의례적 라벨이 아니었다. RFC 3008은 서명이 추가 처리를 받을 자격을 얻기 전에 통과해야 하는 일련의 관문을 기술했다. 데이터 SIG의 경우, type covered 필드는 연관된 RRset과 일치해야 했다. 알고리즘은 인식되고 정의된 SIG 데이터 형식을 가져야 했다. 라벨 수는 서명 소유자 이름의 라벨 수를 초과할 수 없었다. 원본 TTL은 중개자가 이를 늘리는 것이 허용되지 않으므로 현재 SIG TTL보다 낮을 수 없었다. 검증 시각은 발효 시각과 만료 시각 사이에 있어야 했다.
그런 다음 서명자 이름, 키 태그, 알고리즘이 후보 KEY를 식별해야 했다. 이를 만족하는 키가 없으면 서명은 비실질적이었다. 여러 키가 이 선택자들과 일치하면, 암호학적 검증이 서명자를 특정할 때까지 각각 후보로 남았다. 리졸버는 성공한 계산만으로 권위를 추론할 수 없었다. 먼저 어떤 키들의 성공이 의미를 가질지 그 집합을 좁혀야 했다.
KEY 레코드에는 더 많은 관문이 있었다. 그 플래그는 인증을 허용해야 했다. 실질적 데이터 SIG를 위해서는 이름 유형이 zone이어야 했다. 프로토콜 옥텟은 DNSSEC과 무관한 용도가 아니라 DNSSEC 또는 ALL을 가리켜야 했다. 알고리즘은 SIG 알고리즘과 일치해야 했다. 따라서 어떤 키는 올바른 공개 재료를 갖고 올바른 수학을 수행하면서도 잘못된 프로토콜 용도나 잘못된 주체 유형으로 선언되어 있을 수 있었다.
이 순서가 중요하다. 검증은 서명이 후보 키와 커버된 입력에 대응하는지를 답한다. 승인(authorization)은 그 종류의 키가 이런 종류의 DNSSEC 진술을 할 수 있는지를 답한다. 사슬 검증은 리졸버가 해당 영역 키로 가는 신뢰 가능한 경로를 갖고 있는지를 답한다. 이 검사들 이후에도 서명된 데이터는 사용 불가능한 서비스나 현명하지 않은 정책을 기술할 수 있다. 암호학적 무결성이 서명된 진술 밖의 DNS 콘텐츠를 의미적으로 참되게 만들지는 않는다.
RFC 3008은 트랜잭션 보안을 위한 별도의 경로를 유지했다. type covered가 0인 SIG는 DNS 메시지를 보호하며 SIG(0)라고 불렸고,RFC 2931에서 더 자세히 규정되었다. 그 서명자는 영역 키일 필요가 없었다. 트랜잭션은 사용자나 호스트가 개시한다. 네임서버조차 그런 트랜잭션에 영역으로서가 아니라 호스트로서 서명한다. 따라서 기대되는 키 이름 유형은 user 또는 host/주체였고, 영역 키가 SIG(0)를 생성하는 것은 권장되지 않았다.
이는 모순이 아니었다. 호스트 키는 호스트 서명 RRset을 보편적으로 권위 있는 영역 데이터로 공개할 권리를 얻지 않으면서, 어떤 주체가 업데이트 요청을 보냈는지 증명할 수 있었다. 주 서버는 RFC 3007에 따라 인증된 주체에 자신의 로컬 승인 정책을 적용했다. 변경을 수용하면 영역 키가 그 결과 공개 상태에 서명했다. 제안, 수용, 공개 증명은 별개의 권력으로 남았다.
이 구분은 또한 리졸버가 주 서버의 사적 접근 정책을 공개 와이어 형식으로 끌어들이는 것을 막았다. RFC 3007은 업데이트 권한을 의도적으로 로컬 구성에 두었다. 주체는 이름과 RR 유형으로 제한될 수 있었고 기본값은 변경 불가였다. RFC 3008은 RRset 앞선 모든 업데이트 결정을 재구성하도록 요구하지 않으면서, 리졸버에게 표준적인 공개 데이터 기준선을 제공했다.
한 가지 눈에 띄는 메커니즘은 새 권위 모델을 담지 못했다. RFC 3008은 예전 KEY signatory 필드에 어떤 값도 할당하지 않았고, 할당을 요구하지도 않았다. 고정된 signatory 비트는 누가 무엇에 서명할 수 있는지를 인코딩하는 것처럼 보였지만, 변화하는 정책을 편안하게 표현할 수 없었다. 업데이트 수용을 위해서는 정책이 주 서버에 존재했고, 공개 데이터 검증을 위해서는 표준 영역 키 규칙이 수용되는 클래스를 좁혔다. 이 시스템은 몇 비트가 둘 다를 대표할 수 있다고 가장하는 대신, 두 개의 명시적 결정 표면을 사용했다.
이 문서는 여전히 초기 DNSSEC 세대의 일부였다.RFC 3090은 그 모델에서 영역의 보안/비보안 상태가 어떻게 결정되는지를 명확히 했다.RFC 3658은 이후 DS 레코드를 도입하며 권위 사슬의 위임 측면을 갱신했다.RFC 4033,RFC 4034,RFC 4035의 현대적 아키텍처는 결국 RFC 3008을, 그리고 RFC 2535의 KEY·SIG 프레임워크를 폐기했다.
이 수명 주기가 주장의 한계를 정한다. RFC 3008을 현재의 구성 매뉴얼로 제시해서는 안 되며, 그 KEY 플래그를 현대의 DNSKEY·RRSIG 필드로 몰래 치환해서도 안 된다. 2001년 상태 회의 보고서인RFC 3130은 당시 DNSSEC이 구성 요소들이 서로 다른 속도로 발전하던 도구 상자로 이해되었다는 유용한 증거다. 그것은 RFC 3008 모델이 보편적으로 배포되었다거나 그 단순화가 측정된 보안 개선을 가져왔다는 증거가 아니다.
이 문서의 역사적 가치는 권위 검사 그 자체다. 이 표준은 검증자가 서명 연산의 소유를 공개 진실을 정의할 위임으로 취급하면 유효한 토큰조차 위험해질 수 있음을 보았다. 그 대응은 수용되는 역할을 좁히고, 사슬을 경계 짓고, 트랜잭션 신원을 영역 증명과 다른 경로에 두는 것이었다.
Lu Heng의 Running-Code Primacy 렌즈로 읽으면, 권위는 서명 객체가 단순히 존재할 때가 아니라 리졸버 코드가 완전한 분류와 사슬을 실행할 때에만 나타났다. 최소 공통 계층은 영역 키 기준선이었다. 로컬 정책은 그것을 보강할 수 있었지만, 그 예외는 결정을 내리는 리졸버에 귀속되며 다른 모든 이를 위한 일반 규칙을 다시 쓰지 않았다. 안정성은 증거들을 서로 구분해 두는 데서 나왔다. 커버된 데이터, 필드 적격성, 후보 키, 서명자 역할, 암호학적 결과, 사슬, 시간 창.
따라서 RFC 3008은 서명을 덜 마법적이고 더 책임 가능하게 만들었다. 서명자는 키의 소유를 증명할 수 있었다. 키 레코드는 용도를 선언할 수 있었다. 영역 내 위치는 역할을 부여할 수 있었다. 리졸버는 사슬을 검증할 수 있었다. 이 증거들 중 어떤 것도 다른 모든 것을 대신하지 못했다. 서명은 근거 경로와 권위 경로가 같은 결정에서 만날 때에만 의미를 가졌다.
출처
- RFC 3008, Domain Name System Security (DNSSEC) Signing Authority
- RFC 3008 RFC Editor 정보 페이지
- RFC 2535, Domain Name System Security Extensions
- RFC 2931, DNS Request and Transaction Signatures
- RFC 3007, Secure DNS Dynamic Update
- RFC 3090, DNS Security Extension Clarification on Zone Status
- RFC 3130, Notes from the State-Of-The-Technology: DNSSEC
- RFC 3658, Delegation Signer Resource Record
- RFC 4033, DNS Security Introduction and Requirements
- RFC 4034, Resource Records for the DNS Security Extensions
- RFC 4035, Protocol Modifications for the DNS Security Extensions
- Lu Heng, “Running-Code Primacy: The Patch Needed to Preserve the Internet’s Original Design”
- Lu Heng, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption for Internet Coordination Systems”
- Lu Heng, “The Stability Fallacy in the RIR Argument”
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





