요약

  • 에이전트 탐색은 에이전트가 선택되기 전에 조직의 의도를 드러낼 수 있다. 쿼리 본문이 암호화되어 있더라도 기능 필터, 지리, 신뢰 요구사항, 시점 및 반복적 조정이 계획된 작업을 식별할 수 있다.
  • draft-iannone-dawn-privacy-considerations-00은 감시, 저장 데이터, 상관 분석, 식별 위험을 유용하게 명명하지만, 아직 미완성 개인 인터넷 드래프트이며 DNS 비교, 프라이버시 대 감사 가능성 분석, RFC 6973 질의서 및 여러 위협 항목은TBD로 남아 있다.
  • Daniel Kade는 쿼리 세분성, 후보 집합 하한, 연결 가능성 창, 참여자 분리, 부트스트랩 경로, 결과 열람 대상, 보존을 다루는 선택 공개 예산(selection-disclosure budget)을 제안한다. 이는 편집상의 지침이며 DAWN 또는 IETF 요구사항이 아니다.

첫 상호작용에 앞서 이루어지는 첫 공개

탐색은 흔히 의도와 실행 사이를 잇는 무해한 화살표로 그려진다. 클라이언트는 자신의 필요를 알고, 그 필요를 충족할 수 있는 주체를 디렉터리에 물어보고, 답변을 비교하여 하나를 고른다. 신뢰, 권한 부여, 작업 실행은 그 이후에 온다. 이 순서는 탐색을 배관처럼 보이게 한다.

제안된 DAWN 어휘는 이 화살표를 훨씬 크게 만든다. 탐색 가능한 주체는 에이전트, 워크로드 또는 이름이 지정된 리소스일 수 있다. 이들의 속성은 기능, 역량, 프로토콜 지원, 소유권, 지리, 관할권, 신뢰 지표를 기술할 수 있다. 기계 판독 가능한 역량 카드는 사전 관계 없이도 소프트웨어가 수천 가지 가능성을 좁힐 수 있을 만큼 충분한 구조를 노출할 수 있다. 그것이 상호운용 가능한 탐색의 가치다. 동시에 그것이 탐색 요청을 압축된 정책 문서로 만드는 이유이기도 하다.

“번역”에 대한 요청은 광범위하다. 언어 쌍, 의료 데이터 제한, 하나의 증명 방식, 유럽 관할권, 지연 상한, 즉시 가용성을 추가하면 그 요청은 특정 환자 워크플로를 기술할 수 있다. 지연 요구사항을 제거한 뒤 다시 물어보고, 관할권을 바꾼 뒤 또 다시 물어보면, 이 순서 자체가 어느 제약이 협상 가능한지 드러낸다. 기저 목표를 추론하는 데 선택된 에이전트는 필요하지 않다. 검색 경로가 이미 그것을 노출한 것이다.

DAWN 요구사항 드래프트는 선택 메커니즘과 정책을 자신의 범위 밖으로 둔다. 프로토콜을 선택하지 않는 요구사항 문서로서 이 경계는 합리적이다. 그러나 그렇다고 선택 정책이 보이지 않게 되는 것은 아니다. 탐색 서비스가 클라이언트가 검증하는 속성, 그것을 완화하는 순서, 수신하는 후보, 질의 시점을 관찰할 수 있다면, 문서가 명시하기를 거부한 정책을 추론할 수 있다.

이 구분이 핵심이다. 탐색 정보가 진본이고 채널이 기밀이더라도, 탐색이라는 행위 자체는 여전히 정보를 노출할 수 있다. 프라이버시의 대상은 쿼리 문자열만이 아니다. 누가 물었는지, 어떤 속성이 요청되었는지, 몇 개의 후보가 일치했는지, 어떤 결과가 공개되었는지, 그 순서가 언제 발생했는지를 잇는 조인(join)이다.

미완성 드래프트가 올바른 문제를 짚다

연구 기준 시점에서draft-iannone-dawn-privacy-considerations-00은 2026년 5월 22일자 활성 개인 인터넷 드래프트였다. Datatracker에는 RFC 스트림, 담당 Area Director, telechat이 없었으며, 개인 드래프트는 IETF 합의로서 공식적 지위가 없음을 명시적으로 경고했다. 이 지위는 각주가 아니다. 그 문서가 얼마나 많은 권위를 가질 수 있는지를 결정한다.

Revision 00은 솔직하게도 불완전하다. 침입, 잘못된 귀속, 2차 사용, 공개, 배제는TBD로 표시되어 있다. DNS 프라이버시와의 비교와 “프라이버시 대 감사 가능성(Privacy vs Auditability)” 제목의 섹션도 그렇다. RFC 6973 질의서는 답변된 것이 아니라 약속만 되어 있고, DAWN 고유의 완화 범주는 연기되었으며, 보안 고려사항도TBD다. 이러한 공백을 기사가 조용히 채워서는 안 된다.

그래도 존재하는 내용은 가치가 있다. 이 드래프트는 탐색 기반이 감시 지점이 될 수 있다고 말한다. 관찰자는 어떤 에이전트가 어떤 역량을 조회하는지, 조직적 관심사, 워크로드 패턴, 운영 행동을 볼 수 있기 때문이다. 저장된 쿼리 로그와 상호작용 기록이 워크플로와 기업 운영을 노출할 수 있음을 경고한다. 반복 검색에 걸친 상관 분석과 조직 이름, 인프라 소유권, 운영자 신원, 특징적인 역량 메타데이터를 통한 식별을 지목한다.

이 누락은 수임 문제를 명확히 한다. 위협 목록만으로는 운영자가 어느 수준의 노출을 수용할 수 있는지, 그것을 어떻게 검증하는지, 누가 한계를 재정할 수 있는지 알려주지 않는다. 드래프트는 Private Information Retrieval을 가능한 구성 요소로 지목하면서 규모 적합성에 대한 조사를 명시적으로 남겨둔다. PIR은 서버가 어떤 레코드를 반환했는지를 숨길 수 있다. 그러나 그것만으로 쿼리 어휘가 지나치게 구체적인지, 결과 집합이 식별 가능한지, 요청이 시점으로 상관될 수 있는지, 클라이언트가 키와 엔드포인트를 탐색하면서 자기 자신을 노출했는지를 결정하지는 않는다.

암호화는 내용을 보호할 뿐, 선택 전체 표면을 보호하지 않는다

공개된 IETF 프라이버시 작업은 각 메커니즘이 서로 다른 조인을 보호하기 때문에 유용한 비교를 제공한다.

RFC 9156의 DNS 쿼리 이름 최소화는 단순히 전체 이름을 암호화하지 않는다. 각 권위 서버가 그 단계에서 필요한 이름 부분만 받도록 제한한다. 에이전트 탐색에 대한 교훈은 세분성이다. 더 거친 질문으로도 생존 가능한 후보 집합을 유지할 수 있을 때, 완전한 원하는 역량 프로필을 드러내지 말아야 한다.

RFC 9230은 Oblivious DoH 프록시를 대상으로부터 분리한다. 프록시는 클라이언트 연결은 보지만 DNS 질문의 평문은 보지 못하고, 대상은 질문은 보지만 클라이언트 주소는 보지 못한다. RFC 9458은 이 분할을 HTTP에 대해 일반화하면서 메시지 크기, 시점, 키 식별자, 연결 행동, 차별적 처리가 익명 집합을 줄일 수 있음을 경고한다. 암호화가 작동하는 이유는 역할이 분리되어 있고 어느 쪽도 조인을 조용히 재구성할 수 없기 때문이다.

RFC 9540은 한 단계 더 앞서 나간다. 클라이언트는 oblivious 서비스의 존재를 알아내고 게이트웨이 키 구성을 얻어야 한다. 직접 키 요청은 클라이언트 IP를 노출할 수 있다. 고유 경로, 리다이렉트 또는 클라이언트별 키는 보호된 교환이 시작되기 전에 연결 가능성을 복원할 수 있다. 프라이버시에는 부트스트랩 의존성이 있다.

RFC 9576은 Privacy Pass를 통해 관련 지점을 만든다. 발급, 증명, 사용(redeemption)은 분리된 맥락이며, 배포 선택이 당사자들이 그것들을 상관할 수 있는지를 결정한다. RFC 9614는 이를 프라이버시 분할(partitioning), 즉 누구인지와 무엇을 하는지의 분리라고 부르면서도 분할이 만능이 아니라고 경고한다. RFC 7258은 거버넌스 기준선을 더한다. 콘텐츠 또는 외부 특성에 대한 만연한 관찰은 관찰자가 선량한 동기를 주장하든 아니든 공격이다.

이 RFC들은 DAWN을 해결하지 않는다. 범주 오류를 막는다. “암호화된 탐색”은 쿼리 최소화, 후보 집합 크기, 역할 결합, 부트스트랩, 반복, 보존, 예외적 접근에 대해 아무 말도 하지 않는다. 이러한 속성이 별도로 명시되지 않는 한.

후보 집합은 프라이버시 경계다

답변은 질문만큼 많이 공개할 수 있다. 쿼리가 하나의 에이전트를 반환하면, 디렉터리는 선택 기록이 존재하기도 전에 예상 거래 상대방을 드러낸 것이다. 두 개를 반환하면 이후의 네트워크 관찰이 모호성을 해소할 수 있다. 수백 개를 반환하면서 상세한 소유권, 위치, 가용성, 신뢰 메타데이터를 붙이면, 클라이언트는 자신이 고려되었다는 사실조차 모를 수 있는 운영자들에 대해 많은 것을 알게 된다.

DAWN 요구사항 드래프트는 주체들이 무엇을 공개하고 무엇을 제한할지 통제해야 하며, 탐색은 상호작용이 적절한지 판단하는 데 필요한 이상을 공개해서는 안 된다고 말한다. 이 원칙에는 운영상의 분모가 필요하다. “필요한” 정도는 쿼리가 대화형일 때, 속성이 단계적으로 요청될 때, 요청자가 익명일 때, 결과가 캐시될 때, 보안팀이 나중에 로그를 다시 열 수 있을 때 달라진다.

후보 집합 크기는 보편적인 프라이버시 점수가 아니다. 한 회사가 운영하는 열 개의 에이전트는 세 개의 독립 운영자보다 다양성이 낮을 수 있다. 희귀한 속성 조합은 五십 개의 기록이 일치하더라도 요청자의 지문이 될 수 있다. 그럼에도 결과 하한은 중요한 실패 결정을 강제한다. 디렉터리가 하나의 주체 또는 하나의 요청자를 고립시키지 않고는 답할 수 없다면, 답변을 넓혀야 하는가, 질의를 지연해야 하는가, 지연을 추가해야 하는가, 거부해야 하는가?

그 결정은 프로토콜의 거버넌스 표면에 속한다. 조용한 성공은 인덱스 운영자에게 통제권을 넘긴다. 운영자는 클라이언트가 기술적으로 유효한 결과만 받는 동안 얼마나 많은 의도를 노출할지 결정할 수 있다.

선택 공개 예산

배포에 앞서 운영자는 선택 공개 예산을 공표해야 한다. 예산은 중앙 감사 기록이 아니며 원시 쿼리를 보존해서는 안 된다. 각 참여자가 무엇을 알 수 있도록 허용되는지, 예외가 어떻게 만료되는지를 정의하는 유한한 정책 선언이다.

최소한 허용된 속성 클래스와 최대 세분성, 최소 후보 집합 또는 익명 하한, 하한을 충족할 수 없을 때의 행동, 반복 요청이 연결 가능한 상태로 남을 수 있는 창, 배칭·패딩·로테이션 규칙, 요청자 신원·평문 의도·후보 소속·반환된 속성을 보는 당사자를 명시해야 한다. 비합의(non-collusion) 가정을 아키텍처 다이어그램 안에 숨기는 것이 아니라 명시해야 한다.

예산은 질의 이전 경로, 즉 디렉터리, 릴레이, 게이트웨이 또는 키 구성의 탐색도 다루어야 한다. 공개, 제한, 요청자별 결과 필드를 분리하고, 원시 쿼리와 집계 보존에 상한을 두고, 긴급 축소 또는 재식별을 승인할 수 있는 권한을 지목하고, 그 권한에 만료와 검토 조건을 부여하고, 오래된 속성이 결과를 바꾼 경우의 정정 경로를 제공해야 한다.

증거는 프라이버시를 유지한 채로 남을 수 있다. 운영자는 검색어나 후보 신원을 공개하지 않고 결과 집합 밴드 분포, 거부율, 속성 클래스 사용, 예외 수, 보존 컴플라이언스를 공표할 수 있다. 로컬, 단기 카운터는 하한이 적용되었음을 증명할 수 있다. 독립 테스트는 합성 쿼리를 발행하고 각 역할이 무엇을 관찰하는지 비교할 수 있다. 목표는 책임성이라는 이름으로 감시 기록을 재현하는 것이 아니다.

출처

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Lu Heng — Why BTW Media Exists
  4. DAWN Privacy Considerations, revision 00
  5. Datatracker 문서 상태
  6. Datatracker 리비전 이력
  7. DAWN 문제 명세, revision 02
  8. DAWN 요구사항, revision 01
  9. DAWN 용어, revision 01
  10. RFC 6973 — 인터넷 프로토콜의 프라이버시 고려사항
  11. RFC 7258 — 만연적 감시는 공격이다
  12. RFC 9156 — DNS 쿼리 이름 최소화
  13. RFC 9230 — Oblivious DNS over HTTPS
  14. RFC 9458 — Oblivious HTTP
  15. RFC 9540 — Oblivious 서비스의 탐색
  16. RFC 9576 — Privacy Pass 아키텍처
  17. RFC 9614 — 프라이버시를 위한 아키텍처로서의 분할