IETF가 2024년 2월 21일 RFC 9540 "Discovery of Oblivious Services via Service Binding Records"를 표준 제안(Proposed Standard)으로 발표했습니다. 이 문서는 서비스 바인딩(SVCB) 레코드와 HTTPS 레코드에 넣는 새 파라미터 "ohttp"를 정의합니다. 이 파라미터로 어떤 서비스가 Oblivious HTTP(OHTTP)로 접근 가능하다고 DNS에서 알릴 수 있습니다. 클라이언트가 찾아낸 게이트웨이의 키 설정(key configuration)을 받아오는 방법도 함께 정의합니다. 저자는 T. Pauly와 T. Reddy.K입니다.
무엇이 발표되었나
Oblivious HTTP는 클라이언트와 목적지 서버 사이의 메시지를 암호화하는 방식입니다. 이 구조에는 세 가지 역할이 있습니다.
- 대상 리소스(Oblivious Target Resource): 클라이언트가 실제로 이용하려는 서비스
- 게이트웨이 리소스(Oblivious Gateway Resource): 암호화된 메시지를 받아 대상에 전달하는 곳
- 릴레이 리소스(Oblivious Relay Resource): 클라이언트와 게이트웨이 사이에서 메시지를 중계하며 클라이언트의 신원을 가리는 곳
릴레이는 메시지 내용을 볼 수 없습니다. 게이트웨이와 대상은 한 번의 트랜잭션만으로는 클라이언트가 누구인지 알 수 없습니다.
지금까지 OHTTP를 배포할 때는 클라이언트, 릴레이, 게이트웨이가 미리 맞춰 둔 방식으로 키 설정을 주고받는 경우가 많았습니다. RFC 9540은 클라이언트가 대상과 게이트웨이를 더 동적으로 찾을 수 있도록 다음을 정의합니다.
- "ohttp" SvcParamKey: SVCB 또는 HTTPS 레코드에 이 파라미터가 있으면, 해당 서비스가 대상 역할을 할 수 있고 대상에 접근할 수 있는 게이트웨이도 있다는 뜻입니다.
- 게이트웨이 URI 확인: 클라이언트는 대상에서 well-known URI 접미사 "ohttp-gateway"에 접근해 게이트웨이 URI를 알아냅니다. 그래서 이 방식으로 발견되게 하려면 게이트웨이와 대상이 같은 호스트에 있어야 합니다.
- 키 설정 가져오기: 게이트웨이에서 키 설정을 받아오는 방법을 정의합니다.
릴레이를 찾는 방법은 이 문서의 범위에 들어가지 않습니다. 클라이언트에는 신뢰할 수 있는 릴레이가 미리 설정되어 있다고 전제합니다.
영향 범위
RFC가 제시하는 적용 모델은 두 가지입니다.
- 일반 HTTP에서 OHTTP로 전환: 클라이언트가 특정 서비스를 쓰려는데 OHTTP를 지원하면 그쪽을 선호하는 경우입니다. 게이트웨이를 발견하면 요청을 OHTTP로 바꿉니다.
- 대체 OHTTP 서비스 발견: 클라이언트가 OHTTP로 접근하는 공개 DNS 리졸버 같은 기본 대상을 쓰다가, 더 최적화되었거나 더 적합한 응답을 주는 다른 대상을 발견하면 그쪽을 쓰는 경우입니다.
RFC는 DNS 운영과 직접 맞닿은 예도 듭니다. 네트워크가 OHTTP로 접근 가능한 DNS 리졸버를 운영하면서, 지정 리졸버 발견(DDR)이나 네트워크 지정 리졸버 발견(DNR) 같은 방법으로 OHTTP 지원을 알리는 경우입니다.
운영자가 할 일
당장 바꿔야 할 설정은 없습니다. 다만 다음 경우에는 내용을 검토해 두는 것이 좋습니다.
- OHTTP 서비스를 DNS로 알리려는 경우: 권한 DNS 서버에서 SVCB·HTTPS 레코드에 "ohttp" 파라미터를 넣어야 합니다. 사용 중인 DNS 소프트웨어와 관리 도구가 이 파라미터를 처리할 수 있는지 확인하세요.
- 배치를 설계할 때: 이 방식으로 발견되게 하려면 게이트웨이와 대상이 같은 호스트에 있어야 하고, 대상에서 "ohttp-gateway" well-known URI에 응답해야 합니다.
- 리졸버를 OHTTP로 제공하려는 경우: DDR·DNR과 함께 어떻게 알릴지 RFC 본문을 참고하세요.
자세한 내용은 RFC 9540 원문을 확인하시기 바랍니다.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.