Client Authentication Recommendations for Encrypted DNS
draft-jaked-cared-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Tommy Jensen , Jessica Krynitsky , Jeffrey Damick , Matt Engskow , Joe Abley | ||
| Last updated | 2025-10-16 (Latest revision 2025-04-14) | ||
| Replaces | draft-tjjk-cared | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Some encrypted DNS clients require anonymity from their encrypted DNS servers to prevent third parties from correlating client DNS queries with other data for surveillance or data mining purposes. However, there are cases where the client and server have a pre-existing relationship and each wants to prove its identity to the other. For example, an encrypted DNS server may only wish to accept queries from encrypted DNS clients that are managed by the same enterprise, and an encrypted DNS client may need to confirm the identity of the encrypted DNS server it is communicating with. This requires mutual authentication. This document discusses the circumstances under which client authentication is appropriate to use with encrypted DNS, the benefits and limitations of doing so, and recommends authentication mechanisms to be used when communicating with TLS-based encrypted DNS protocols.
Authors
Tommy Jensen
Jessica Krynitsky
Jeffrey Damick
Matt Engskow
Joe Abley
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)