Oblivious CoAP는 보낸 이를 숨긴다. 중계자는 요청을 두 번 보낼 수 있다

요약

• 새 Oblivious CoAP 초안에서 프록시는 기기의 주소를 보지만 보호된 요청을 읽지 못하고, 게이트웨이는 요청을 복호화하지만 프록시로부터 기기 주소를 받지 않는다.
• 초안 7.1절은 프록시나 외부 공격자가 암호화된 요청을 쉽게 재전송할 수 있다고 적는다. 상태를 바꾸는 요청이라면 수신 서버가 첫 메시지의 식별값과 이후 메시지의 카운터를 관리해야 한다.

봉투를 열 수 없어도 복사해서 두 번 배달할 수는 있다. 10월 28일 자 Oblivious CoAP 초안이 보여주는 불편한 장면이다. 기기는 누가 보냈는지 목적지에 알리지 않고 요청할 수 있다. 그 사이의 프록시는 내용을 모른 채 동일한 암호문을 다시 보낼 수 있다. 프라이버시를 위한 분리는 중복 실행의 책임을 없애지 않는다.

CoAP는 자원이 제한된 기기의 요청과 응답을 다룬다. 초안이 제시한 용도는 DNS over CoAP 질의, 익명 기기 진단 자료, 리소스 디렉터리 질의다. 이것들은 배포 실적이 아니라 제안된 사례다. 기기는 원래 교환 내용을 HPKE로 게이트웨이용 암호문으로 만들고 CoAP 프록시에 넘긴다. 프록시는 출발 주소만 보고, 게이트웨이는 복호화된 내용을 본다. 두 역할이 같은 운영 주체 아래 로그를 합치면 분리된 정보도 다시 이어질 수 있다.

구조는 Oblivious HTTP의 두 역할 모델을 떠올리게 한다. CoAP 초안에는 하나의 HPKE 맥락으로 이어지는 후속 메시지를 다루는 장치도 있다. 운영에 협조하는 게이트웨이가 필요하다는 제한 역시 초안에 명시돼 있다. 따라서 모든 CoAP 서버에 끼워 넣을 수 있는 만능 익명성 기능으로 읽으면 안 된다. 프록시가 다시 보낸 암호문은 수신 쪽에서 원래 요청과 같은 효과를 낼 수 있다.

초안 7.1절은 처리 방법을 나눈다. 서버가 실제로 안전한 메서드임을 확인했다면 재전송을 받아들일 수 있다. 상태를 바꾸는 요청은 중복을 찾아 적절할 때 처리를 멈출 수 있다. 교환의 첫 요청은 HPKE 캡슐화 값 enc 또는 그 해시로 구별한다. 같은 HPKE 맥락의 후속 요청에는 무결성이 보호된 OCoAP count를 사용하고, 수신 맥락에 붙은 재전송 창과 비교한다. 보호된 Echo 옵션은 신선도 확인을 더할 수 있다.

문제는 이 확인 절차가 서버의 기억에 의존한다는 점이다. 어느 메서드가 정말 다시 실행해도 안전한지 애플리케이션이 판단하고, 게이트웨이는 이미 받은 봉투의 흔적을 보관해야 한다. 진단 메시지를 두 번 세면 기록이 흔들리고, 상태 변경 요청을 두 번 실행하면 결과도 두 번 생길 수 있다. 초안은 필요한 식별 수단을 제시하지만 저장량, 보존 기간, 재시작 뒤 복구 방식, 실제 현장 시험 결과는 측정해 싣지 않았다.

Datatracker 기록은 이 문서를 I-D Exists 상태의 개별 Standards Track 초안으로 표시한다. 다음 시험은 분명하다. 첫 암호화 요청과 그 복사본을 보내고 같은 교환의 후속 요청도 반복한다. 게이트웨이를 재시작한 뒤 다시 시험한다. 무엇이 한 번만 실행됐는지, 재전송 기록이 얼마나 남았는지, 누가 송신자와 요청을 다시 연결할 수 있는지를 기록하면 된다.