I realize this is a bit beyond the scope of UTA, but experience has shown that having multiple mechanisms to do the same thing is just going to create more problems for us down the road.
Eliot On 28.10.2024 17:54, Tommy Jensen wrote:
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 touta-le...@ietf.org_______________________________________________ Uta mailing list --uta@ietf.org To unsubscribe send an email touta-le...@ietf.org
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Uta mailing list -- uta@ietf.org To unsubscribe send an email to uta-le...@ietf.org
