Hi Tommy, Encrypted DNS servers SHOULD NOT attempt to authenticate clients to identify the appropriate resolution policy to use when the difference in resolution behavior between them is not imposed by the operator of the server but instead is chosen by the client. There are certain use-cases where the appropriate resolution policy is chosen by the client (actually user), but where sending queries to a different IP address would not work. For example, per-user block/allow lists, or per-user decisions about what kind of content should be allowed (no adult content for example). In those cases, authentication would be needed.
You state in reply to Eliot Lear: > 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. > Which I agree with, but I think the above SHOULD NOT is overly restrictive for the use-case mentioned. Neil > On 20 Oct 2024, at 22: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
