I think mTLS (client certs) makes sense as a recommendation in draft-tjjk-cared, but is critical to call out the privacy issues with TLS client certs in TLS versions prior to TLS 1.3. (ie, in TLS 1.2 and before the client certificates are sent in-the-clear in the handshake unless renegotiation is used.)
The best fix might be to have a "MUST use only TLS 1.3 or above with no fallback" and call out the risks of doing otherwise in Security Considerations. Erik On Thu, Jun 27, 2024 at 11:42 AM Tommy Jensen <Jensen.Thomas= 40microsoft....@dmarc.ietf.org> wrote: > > Spoiler alert: we prefer mTLS as the ideal authentication mechanism. I'll > let the draft speak for itself as to why. Feedback and discussion is > welcome. > > Thanks, > Tommy > > ------------------------------ > *From:* internet-dra...@ietf.org <internet-dra...@ietf.org> > *Sent:* Thursday, June 27, 2024 11:32 AM > *To:* Jeffrey Damick <jdam...@amazon.com>; Jessica Krynitsky < > jess.krynit...@microsoft.com>; Matt Engskow <mengs...@amazon.com>; Tommy > Jensen <jensen.tho...@microsoft.com> > *Subject:* [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt > > A new version of Internet-Draft draft-tjjk-cared-00.txt has been > successfully > submitted by Tommy Jensen and posted to the > IETF repository. > > Name: draft-tjjk-cared > Revision: 00 > Title: Client Authentication Recommendations for Encrypted DNS > Date: 2024-06-27 > Group: Individual Submission > Pages: 11 > URL: https://www.ietf.org/archive/id/draft-tjjk-cared-00.txt > Status: https://datatracker.ietf.org/doc/draft-tjjk-cared/ > HTML: https://www.ietf.org/archive/id/draft-tjjk-cared-00.html > HTMLized: https://datatracker.ietf.org/doc/html/draft-tjjk-cared > > > 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. > > > > The IETF Secretariat > > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
