요약

  • DNS 쿠키는 성공한 왕복 한 번을, 나중의 UDP 요청이 동일한 표면상 출발지 주소와 클라이언트 쿠키에서 왔다는 제한적인 증거로 바꾸어, 오프패스 출발지 위조의 유용성을 떨어뜨리면서 신원이나 기밀성은 만들지 않습니다.
  • RFC 7873이 교환을 정의했고, RFC 9018은 16바이트 버전 1 구조, SipHash-2-4 생성 방식, 운영 비밀 롤오버 절차를 고정함으로써 혼합 애니캐스트 구현 간에 서버 쿠키를 상호 운용 가능하게 만들었습니다.
  • 이 메커니즘은 의도적으로 범위가 한정되어 있습니다: 경로상의 관찰자는 쿠키가 유효한 동안 눈에 보이는 쿠키를 재사용할 수 있고, NAT는 많은 클라이언트를 하나의 공용 주소 뒤로 합칠 수 있으며, 서버는 여전히 속도 제한과 다른 DNS 방어 수단이 필요합니다.

처음에는 공유 계정도, 인증서도, 협상된 키도 없습니다. 출발지 주소가 진짜일 수도 위조일 수도 있는 UDP 요청만 있을 뿐입니다. DNS 클라이언트는 EDNS COOKIE 옵션에 8바이트 클라이언트 쿠키를 추가합니다. 서버가 이 메커니즘을 지원하면 그 값을 자체 서버 쿠키와 함께 돌려보냅니다. 클라이언트는 이 쌍을 저장하고, 이후 쿼리에서 둘 다 제시합니다.

그 두 번째 요청은 적지 않은 역사를 담고 있습니다. 서버 쿠키는 클라이언트 쿠키, 표면상의 클라이언트 주소, 서버가 보유한 비밀 자료로부터 계산되었습니다. 피해자의 주소를 IP 헤더에 쓰기만 하는 오프패스 발신자는 이전 응답을 보지 못했을 것이므로, 일치하는 토큰을 가지고 있지 않을 것입니다. 서버는 유효한 쌍을, 이 주소-쿠키 조합과 이전에 트래픽을 주고받은 적이 있다는 증거로 취급할 수 있습니다. 클라이언트 쪽에서도 자신이 기대했던 클라이언트 쿠키를 돌려주지 않는 응답은 거부할 수 있습니다.

이것은 신원이 아닙니다. 가정용 게이트웨이, 캐리어급 NAT 또는 기업 엣지는 여러 기기를 하나의 공용 주소로 공유하게 만들 수 있습니다. 올바른 주소에 있는 침해된 기기도 여전히 악의적으로 동작할 수 있습니다. 경로상의 관찰자는 평문 쿠키를 보고 그 유효 기간 동안 재사용할 수 있습니다. DNS 쿠키는 질문을 암호화하지도 않고 이름의 소유자를 인증하지도 않으며, UDP를 책임 있는 세션으로 바꾸지도 않습니다. 이 메커니즘이 이룬 것은 더 작습니다: 특정한 거짓말—이전 트래픽을 받지 못한 주소에서 패킷이 왔다는 오프패스 주장—의 비용을 올리는 것입니다.

그 거짓말은 DNS가 이를 증폭할 수 있었기 때문에 문제가 되었습니다. 위조된 출발지 주소를 가진 짧은 질문 하나가 피해자를 향해 더 큰 응답을 유도할 수 있었습니다. 위조된 요청은 재귀 서버가 조회와 DNSSEC 검증에 작업을 소모하게 만들 수도 있었습니다. 반대 방향으로는 위조된 응답이 정당한 답변과 경합을 벌여 리졸버의 캐시 오염을 시도할 수 있었습니다.

기존의 방어 수단들은 서로 다른 표면을 다루었습니다. DNSSEC는 DNS 데이터를 인증하지만 메시지를 크게 만들 수 있고 검증 작업을 요구합니다. TSIG는 더 강한 트랜잭션 인증을 제공하지만 공유 키 관리를 전제로 합니다. 출발지 포트와 트랜잭션 ID 엔트로피는 맹목적인 응답 추측을 어렵게 만듭니다. 응답 속도 제한은 출력을 억제합니다. DNS 쿠키는 가볍고 상태를 저장하지 않는 반환 경로 증거로 이러한 통제를 보완하도록 설계되었습니다.

2016년 5월에 발표된 RFC 7873은 그 증거를 EDNS 옵션 코드 10에 담았습니다. 알려진 서버 쿠키가 없으면 옵션은 8바이트 클라이언트 쿠키만 담습니다. 클라이언트가 서버 쿠키를 학습한 이후에는 옵션이 둘 다 담습니다. 원래 규격은 서버 쿠키를 8~32바이트로 허용했고 그 비공개 생성 방식은 구현에 맡겼습니다. 서버는 클라이언트마다 저장 레코드를 둘 필요가 없었습니다: 요청 주소, 클라이언트 쿠키, 비밀로부터 토큰을 다시 계산할 수 있었습니다.

상태 머신은 부분 배포와의 호환성을 의도적으로 갖추었습니다. DNS 쿠키를 구현하지 않는 서버는 옵션을 무시합니다. 클라이언트 쿠키만 받은 지원 서버는 정책에 따라 요청을 드롭하거나,BADCOOKIE로 응답하거나, 정상적으로 처리할 수 있습니다; 응답할 때는 클라이언트가 더 강한 상태로 이동할 수 있도록 서버 쿠키를 함께 제공합니다. 형식이 잘못된 옵션은FORMERR를 낳습니다. 유효하지 않거나 오래된 서버 쿠키는 없는 것처럼 취급됩니다. 유효한 쿠키는 서버가 스푸핑된 UDP 출발지 주소를 방어하기 위해서만 존재하는 조치를 완화할 수 있게 해줍니다—서버가 가진 모든 악용 방지 통제가 아니라 그것만입니다.

따라서BADCOOKIE는 단순한 오류 이름이 아닙니다. 그것은 전환입니다. 응답 안의 일치하는 클라이언트 쿠키는 클라이언트에게 이 응답이 자신의 교환에 속한다는 것을 알려주고, 새로 돌려받은 서버 쿠키는 재시도에 필요한 값을 제공합니다. 새 값을 받자마자 다시 실패한다면, 프로토콜은 TCP를 폴백으로 가리킵니다. 반복되는 실패는 운영상 결함도 드러낼 수 있습니다: 애니캐스트 서비스의 구성원들이 비밀이나 쿠키 생성 방식에 대해 불일치할 수 있습니다.

NAT는 왜 이 설계가 양쪽 절반을 필요로 하는지 설명해 줍니다. 서버 쿠키를 공용 출발지 주소에만 묶으면, 게이트웨이 뒤의 한 기기가 그 주소를 공유하는 모든 다른 기기가 사용할 수 있는 토큰을 얻을 수 있습니다. 서버 계산에 클라이언트 쿠키를 포함하면 서버가 각 클라이언트를 기억하지 않고도 그 흐름들을 구별합니다. 결과는 여전히 개별 신원이 아닙니다—서버가 보는 것은 NAT의 공용 주소입니다—하지만 그것은 와이어에서 이용 가능한 세분성으로 메커니즘의 좁은 주장을 보존합니다.

애니캐스트는 더 어려운 역사적 문제를 만들었습니다. 하나의 서비스 주소가 연속된 패킷을, 아마도 서로 다른 DNS 소프트웨어를 실행하는, 서로 다른 기기들에 전달할 수 있습니다. RFC 7873은 공유 서버 비밀을 권고했지만 구현이 입력을 서버 쿠키로 바꾸는 방식은 표준화하지 않았습니다. 두 공급업체가 같은 비밀을 가지고도 서로 이해할 수 없는 토큰을 만들어 낼 수 있었습니다. 한 노드에서 다른 노드로 라우팅된 클라이언트는 악의적인 일이 아무것도 없었음에도 나쁜 쿠키를 가져온 것처럼 보였습니다.

2021년 4월에 발표된 RFC 9018은 그 구현 자유를 상호 운용 가능한 형식으로 바꾸었습니다. 버전 1 서버 쿠키는 16바이트입니다: 버전 1바이트, 예약 3바이트, 타임스탬프 4바이트, SipHash-2-4 출력 8바이트. 8바이트 클라이언트 쿠키와 함께 전체 옵션은 정확히 24바이트입니다. 해시는 클라이언트 쿠키, 눈에 보이는 구조적 필드들, 클라이언트 IP 주소, 공유 서버 비밀을 포괄합니다. 주소는 쿠키 자체에 복사되지 않고 검증에 영향을 줍니다.

타임스탬프는 토큰에 명시적인 재사용 지평을 부여합니다. RFC 9018은 1시간 이상 오래된 값은 받아들이지 말고 최대 5분의 미래 시간 오차는 허용하며, 쿠키가 30분 이상 오래되면 새로 고치도록 권고합니다. 이는 표준 권고사항이며 모든 배포가 동일한 타이머를 사용한다는 증거는 아닙니다. 그러나 토큰이 만료되도록 설계되었다는 것은 보여줍니다. 경로상의 관찰자는 이를 캡처하면서 토큰과 그 사용 가능 기간을 모두 알아냅니다; 이 메커니즘은 관찰을 제거하지 않고 재사용 범위를 좁힙니다.

상호 운용성은 또한 비밀 로테이션을 애니캐스트 조정 문제로 만들었습니다. 새 비밀은 먼저 모든 노드에 도달해야 하며, 그 동안 모든 노드는 이전 비밀로 쿠키를 발급하면서 둘 다 검증해야 합니다. 배포가 완료된 후에야 노드들은 새 비밀로 발급을 시작하고 여전히 이전 비밀을 검증합니다. 이전 값은 클라이언트들이 새로 고칠 시간을 가진 뒤에야 은퇴시킬 수 있습니다. 시계 동기화는 비밀 일관성과 함께 프로토콜의 통제 표면의 일부가 됩니다. 암호 기법 하나만으로는 시간이나 롤아웃 단계에 대해 불일치하는 플릿을 구할 수 없습니다.

RFC 9018은 클라이언트 쿠키 지침도 바꾸었습니다. 쿠키가 만들어질 때 흔히 알 수 없는 클라이언트 주소를 포함하는 해시를 요구하는 대신, 서버 IP마다 64비트의 엔트로피를 권고합니다. 클라이언트는 자신의 IP 주소가 바뀐 후에는 쿠키 재사용을 멈추어야 합니다. 네트워크를 넘어서 지속되는 안정적인 토큰은 추적 수단이 될 수 있기 때문입니다. 서버가 쿠키를 지원한다고 알려지지 않았을 때, 클라이언트는 실패한 동일한 식별자를 계속 제시해서는 안 됩니다. NAT는 잔여 한계를 남깁니다: 호스트는 자신의 게이트웨이 공용 주소가 바뀌었다는 것을 모를 수 있고, 공용 주소 자체는 서버에게 여전히 관찰 가능합니다.

그러므로 DNS 쿠키의 역사는 DNS가 신원을 얻은 이야기가 아닙니다. 그것은 증거가 실제로 뒷받침할 수 있는 주장에 맞춰진 이야기입니다. 첫 교환은 의도에 대해 거의 아무것도 증명하지 않습니다. 그것은 다음 출발지 주소 주장을 오프패스에서 위조하기 더 비싸게 만드는 토큰을 만듭니다. RFC 7873이 그 거래를 정의했고, RFC 9018이 다양한 애니캐스트 플릿 전반에서 그것을 작동 가능하게 만들었으며, 그 과정에서 진짜 권한이 어디에 있는지 드러냈습니다: 클라이언트 재사용 정책, 서버 응답 정책, 동기화된 시간, 공유 비밀의 규율 있는 관리에 있습니다.

출처