Client Authentication Recommendations for Encrypted DNS
draft-tjjk-cared-00
| Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Tommy Jensen , Jessica Krynitsky , Jeffrey Damick , Matt Engskow | ||
| Last updated | 2024-06-27 | ||
| Replaced by | draft-jaked-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 | Replaced by draft-jaked-cared | |
| 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
For privacy reasons, encrypted DNS clients need to be anonymous to 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 peer wants to prove its identity to the other. For example, an encrypted DNS server may only wish to accept resolutions from encrypted DNS clients that are managed by the same enterprise. This requires mutual authentication. This document defines when using client authentication with encrypted DNS is appropriate, the benefits and limitations of doing so, and the recommended authentication mechanism(s) when communicating with TLS- based encrypted DNS protocols.
Authors
Tommy Jensen
Jessica Krynitsky
Jeffrey Damick
Matt Engskow
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)