요약

  • RFC 3090은 알고리즘별 라벨과 "실험적으로 안전" 라벨을 대체하여 전역 보안, 로컬 보안, 비보안이라는 세 가지 존 속성을 도입했습니다.
  • 이 라벨들은 보편적 보호를 보장하지 않았습니다. 리졸버는 여전히 자체 트러스트 앵커, 지원 알고리즘, 선택한 검증 경로, 부모-자식 경계에 대한 관점을 통해 이분법적 판단에 도달했습니다.

네 명의 관찰자가 같은 질문을 서로 다른 의미로 던질 수 있었다

2001년 3월 무렵, DNSSEC에는 암호학적 문제만큼이나 어휘 문제가 있었습니다. RFC 2535는 서명된 데이터와 신뢰 사슬을 기술했지만 배포는 불완전했습니다. 부모 존이 DNS 루트와 연결할 수 있기 전에 존이 레코드를 서명할 수 있었습니다. 리졸버는 고립된 존을 직접 신뢰하도록 구성될 수 있었습니다. 알고리즘은 한 구현에서는 이해되고 다른 구현에서는 그렇지 않을 수 있었습니다. 존이 단순히 "안전"하다고 말하는 것은 여러 조건을 하나의 단어로 압축해, 근거가 허용하는 것보다 더 절대적인 것처럼 들리게 했습니다.

RFC 3090은 관찰자들을 분리하는 것으로 시작했습니다. 존 관리자는 어떤 데이터를 게시할지 결정해야 했습니다. 보안 동적 업데이트 서버는 존을 어떻게 유지할지 알아야 했습니다. 부모는 자식의 상태를 표명해야 했습니다. 리졸버는 답변이 검증될 수 있는지 판단해야 했습니다. 각자 서로 다른 통제 표면을 바라보고 있었습니다. 내용에 서명하는 것은 자식의 행위였고, 위임 경로를 제공하는 것은 부분적으로 부모의 행위였으며, 신뢰 루트와 알고리즘을 수용하는 것은 리졸버 운영자의 행위였습니다.

따라서 이 메모는 하나의 존이 알고리즘마다 다른 상태를 가질 수 있다는 구버전 개념을 제거했습니다. 존은 하나의 행정적 분류를 받게 됩니다. 또한 "실험적으로 안전"을 폐기했습니다. 실험은 네 번째 형이상학적 상태가 아니었습니다. 그 키로 구성된 리졸버에게는 존이 로컬 보안 섬을 형성했고, 일반 리졸버에게는 비보안이었습니다.

섬은 어디에 착륙할지 아는 리졸버에게만 존재했다

인터넷은 끊기지 않은 서명 트리가 완성되기를 기다리지 않고도 DNSSEC을 시험할 수 있었습니다. 비보안 부모 아래의 연속된 서명 존들은 보안의 섬을 형성할 수 있었습니다. 그 섬의 루트 키는 트러스트 앵커로 선정된 리졸버에 설치될 수 있었습니다. 그 리졸버들은 DNS 루트에서 신뢰 사슬이 닿지 않음에도 섬 내부를 아래 방향으로 검증할 수 있었습니다.

이 배치가 RFC 3090의 가장 유용한 역사적 결과를 낳았습니다. 같은 존이 한 집단에게는 로컬 보안이고 다른 집단에게는 비보안일 수 있었습니다. 두 질의 사이에 권위 있는 존 파일은 아무것도 바뀔 필요가 없었습니다. 달라진 것은 리졸버 상태였습니다. 한 기계는 인정된 시작 키와 수용 가능한 경로를 가졌고, 다른 기계는 그렇지 않았습니다.

여러 구성된 루트를 가진 리졸버조차 올바른 것에서 시작해야 했습니다. RFC 3090은 가장 가까운 보안 루트를, 질의된 이름에 대해 가장 오른쪽 라벨들의 정렬된 일치가 가장 큰 구성된 루트로 정의했습니다. 더 먼 앵커에서 시작한 리졸버는 경로에서 서명된 NULL 키를 만나 자손이 비보안이라고 결론 내리고, 더 가까이 구성된 섬을 놓칠 수 있었습니다. 따라서 겹치는 섬들은 아키텍처 슬라이드의 그림 이상이었습니다. 구체적인 구성 및 구현 위험을 만들어냈습니다.

이것이 포획된 서명이 증명의 전부가 아닌 이유입니다. 조사자는 리졸버의 앵커 집합, 시작점을 선택한 이름 선택 논리, 알고리즘 지원, 실제로 검색된 레코드, 정책이 적용된 시점도 필요로 합니다. 검증 결과는 그렇게 조립된 경로에 대한 진술이지, 존에 새겨진 영속적 속성이 아닙니다.

부모는 침묵을 게시함으로써 말할 수 있었다

위임 경계는 RFC 2535 세대의 또 다른 불편한 관례를 노출했습니다. 보안 부모는 보안 자식과 비보안 자식을 구분해야 했습니다. 명확화된 규칙에서는 부모 측에 자식 KEY가 없다는 것이 자식이 보안임을 나타내고, 명시적으로 서명된 NULL 키가 비보안 자식을 나타낼 수 있었습니다.

RFC 3090은 이를 직관에 어긋난다고 불렀습니다. 운영자는 통상 긍정적 보안 주장이 긍정적 증거를 남기리 기대합니다. 여기서는 보안 사례가 침묵으로, 비보안 사례가 서명된 객체로 표현될 수 있었습니다. 이 문서는 프로토콜을 재설계하지 않고, 구현자에게 상속된 메커니즘을 어떻게 해석할지 경고하고 운영상의 불편함을 인정했습니다.

따라서 결여(부재)를 일반적 증거로 취급할 수 없습니다. 그것은 특정 프로토콜 세대 내부에서, 특정 경로의 특정 인증된 지점에서만 의미를 가집니다. KEY 레코드가 없는 패킷 캡처만으로는 보안 자식을 독립적으로 증명하지 못합니다. 먼저 부모 자신이 보안이었는지, 관련 레코드와 부정적 증거가 획득되었는지, 역사적 규칙이 적용되었는지를 확립해야 합니다.

이후의 DNSSEC은 이 다리를 바꾸었습니다. RFC 3658이 DS를 도입했고, RFC 4033, 4034, 4035는 구버전 KEY, SIG, NXT 아키텍처를 DNSKEY, RRSIG, NSEC, DS로 대체했습니다. 이후 용어들은 현대의 신뢰 사슬을 더 쉽게 인식하게 해주지만, RFC 3090이 이미 그것들을 명시했던 것처럼 소급 적용해서는 안 됩니다.

"전역"은 안전 인증서가 아니라 경로를 기술했다

RFC 3090은 까다로운 조건하에서 전역 보안 존을 정의했습니다: 필수 알고리즘, 트리 내 부모 서명 사슬, 적절한 아펙스 존 서명 KEY 자료, NXT 커버리지, 자격 있는 레코드 집합에 대한 서명. 로컬 보안 존은 요구되는 서명 존 속성을 유지하면서 다른 알고리즘이나 트리 밖의 사전 구성된 검증 경로에 의존할 수 있었습니다. 그 외의 것은 모두 비보안이었습니다.

그러나 문서는 "전역"과 "로컬"이 표준 준수의 선언이 아니라 속성임을 명시적으로 말했습니다. 제한적인 리졸버는 전역 보안 존만 수용할 수 있었습니다. 더 유능하거나 특수하게 구성된 리졸버는 로컬 보안 존을 검증할 수 있었습니다. 사용 시점에 각 리졸버는 여전히 이분법적 답을 내놓았습니다. 보안 또는 비보안.

가장 강한 라벨도 올바른 동작을 보장할 수 없었습니다. 표준 준수는 강제될 수 없었습니다. 결함이 있는 리졸버는 나쁜 데이터를 수용할 수 있었습니다. 침해되었거나 표준을 따르지 않는 부모는 세심한 자식의 노력을 끊을 수 있었습니다. 상태 어휘는 책임과 증거를 조직했을 뿐, 적대자나 구현 실패를 없애지 않았습니다.

이 절제가 지속되는 교훈입니다. DNSSEC 보안은 행정 경계를 넘어 조립됩니다. 자식은 서명된 내용을, 부모는 위임 표명의 일부를, 리졸버 운영자는 앵커와 수용 가능한 알고리즘을 통제하고, 프로토콜은 그 사실들이 어떻게 합성되는지 정의합니다. 어떤 참여자도 자신의 올바른 행위만으로 보편적 신뢰로 전환할 수 없습니다.

출처

  1. https://www.rfc-editor.org/info/rfc3090
  2. https://www.rfc-editor.org/rfc/rfc3090.html
  3. https://www.rfc-editor.org/rfc/rfc3090.txt
  4. https://datatracker.ietf.org/doc/rfc3090/
  5. https://www.rfc-editor.org/errata/rfc3090
  6. https://www.rfc-editor.org/rfc/rfc2535.html
  7. https://www.rfc-editor.org/rfc/rfc3007.html
  8. https://www.rfc-editor.org/rfc/rfc3008.html
  9. https://www.rfc-editor.org/rfc/rfc3658.html
  10. https://www.rfc-editor.org/rfc/rfc4033.html
  11. https://www.rfc-editor.org/rfc/rfc4034.html
  12. https://www.rfc-editor.org/rfc/rfc4035.html
  13. https://www.rfc-editor.org/rfc/rfc5011.html