Hey Eliot, My opinion offered from an airport gate, without prior discussion with coauthors:
If we need to rework the doc to do so, I want to make sure we aren't "allowing" or "not allowing" anything, rather recommending things based on justified criteria then adding considerations for other things as appropriate (see the PSK text). If implementors want to use other auth mechanisms, fine, we just want to recommend a min set so we can maximize interop likelihood. As I write this, maybe the section on alternatives that did not meet all criteria could have softer language in the "these may work if X and Y do not apply to you". The point being we don't want to say someone SHOULD NOT do any auth option. Our NOTs are reserved for when a peer really shouldn't request or offer auth at all. As for why HTTP auth mechanisms did not make the recommendation, its because they would be DoH specific, and for interop purposes, we want to recommend approaches that would work across any TLS-based encrypted DNS protocol. Thanks, Tommy 2024-10-28T16:47:01Z Eliot Lear <l...@lear.ch>: > Hi Tommy, > > I reviewed the draft. It brings forward an important architectural question: > should one size fit all in this case? That is, if you're doing DoH, why not > allow the full range of HTTP capabilities to come to bear? > > Eliot > > On 20.10.2024 23:27, tojens.i...@gmail.com wrote: >> Good day, uta WG: >> >> We have written a draft talking about when encrypted DNS clients should (and >> should not) utilize client authentication and how best to do so. After >> consideration in the dnsop WG at IETF 120, the chairs and ADs agreed that it >> would be more appropriate to discuss this here because of our focus on using >> TLS mechanisms. >> >> We welcome your feedback! >> >> Thanks, >> Tommy >> >>> -----Original Message----- >>> From: internet-dra...@ietf.org <internet-dra...@ietf.org> >>> Sent: Sunday, October 20, 2024 2:21 PM >>> To: Jeffrey Damick <jdam...@amazon.com>; Jessica Krynitsky >>> <jess.krynit...@microsoft.com>; Joe Abley <jab...@cloudflare.com>; Matt >>> Engskow <mengs...@amazon.com>; Tommy Jensen <tojens.i...@gmail.com> >>> Subject: New Version Notification for draft-jaked-cared-00.txt >>> >>> A new version of Internet-Draft draft-jaked-cared-00.txt has been >>> successfully >>> submitted by Tommy Jensen and posted to the IETF repository. >>> >>> Name: draft-jaked-cared >>> Revision: 00 >>> Title: Client Authentication Recommendations for Encrypted DNS >>> Date: 2024-10-20 >>> Group: Individual Submission >>> Pages: 12 >>> URL: https://www.ietf.org/archive/id/draft-jaked-cared-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-jaked-cared/ >>> HTML: https://www.ietf.org/archive/id/draft-jaked-cared-00.html >>> HTMLized: https://datatracker.ietf.org/doc/html/draft-jaked-cared >>> >>> >>> 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. >>> >>> >>> >>> The IETF Secretariat >>> >> >> >> _______________________________________________ >> Uta mailing list -- uta@ietf.org >> To unsubscribe send an email to uta-le...@ietf.org >>
_______________________________________________ Uta mailing list -- uta@ietf.org To unsubscribe send an email to uta-le...@ietf.org
