Hi all, Coming to this discussion late, but thanks to the authors for bringing this draft. I work for the UK National Cyber Security Centre, and several years ago we created a Protective DNS (PDNS) service for the UK public sector – exactly the sort of DNS resolution service where client authentication is used. Given that, I’m very supportive of providing guidance on a secure baseline to aid interoperability and migration between different Protective DNS services.
One immediate suggestion: I think that the security value provided by these Protective DNS services (as mentioned in the draft) could be called out explicitly in the Security Considerations section - I’d be happy to contribute text if the authors/WG think this would be useful. RFC 9424 (of which I’m an author) covers some of the benefits from deploying Indicators of Compromise to Protective DNS services, so could be a useful reference here too. To your point on DoT, Eliot, given plenty of services already exist (and may operate in a wide variety of ways), in the interests of helping this draft to be as applicable as possible, I’d support keeping the draft agnostic on the choice of encrypted DNS protocol. And, as you say, that’s probably a conversation beyond the scope of this draft in any case. Thanks, Andy From: Eliot Lear <l...@lear.ch> Sent: 28 October 2024 18:06 To: Tommy Jensen <tojens.i...@gmail.com> Cc: uta@ietf.org; 'Jeffrey Damick' <jdam...@amazon.com>; 'Jessica Krynitsky' <jess.krynit...@microsoft.com>; 'Joe Abley' <jab...@cloudflare.com>; 'Matt Engskow' <mengs...@amazon.com> Subject: [Uta] Re: New Version Notification for draft-jaked-cared-00.txt Well, I was thinking about that entire Section 7, and wondering if perhaps it's time to retire a few mechanisms, and I was specifically thinking of DoT. DoH seems to cover that ground well. Do we have a strong use case for where DoT is useful where DoH is not? 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><mailto: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<mailto: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<mailto:internet-dra...@ietf.org> <internet-dra...@ietf.org><mailto:internet-dra...@ietf.org> Sent: Sunday, October 20, 2024 2:21 PM To: Jeffrey Damick <jdam...@amazon.com><mailto:jdam...@amazon.com>; Jessica Krynitsky <jess.krynit...@microsoft.com><mailto:jess.krynit...@microsoft.com>; Joe Abley <jab...@cloudflare.com><mailto:jab...@cloudflare.com>; Matt Engskow <mengs...@amazon.com><mailto:mengs...@amazon.com>; Tommy Jensen <tojens.i...@gmail.com><mailto: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<mailto:uta@ietf.org> To unsubscribe send an email to uta-le...@ietf.org<mailto:uta-le...@ietf.org> _______________________________________________ Uta mailing list -- uta@ietf.org<mailto:uta@ietf.org> To unsubscribe send an email to uta-le...@ietf.org<mailto:uta-le...@ietf.org>
_______________________________________________ Uta mailing list -- uta@ietf.org To unsubscribe send an email to uta-le...@ietf.org
