I am generally skeptical of the idea that we should write recommendations that are "for enterprise". The notion of "enterprise" is too slippery for technical standards. Enterprises are also technically integrated by definition, so they are less reliant on technical standards than multi-party arrangements.
This draft is framed as making the argument for choosing mTLS as the authentication mechanism for DoE, but I don't think this choice is within the IETF's purview. Operators are free to deploy any compatible authentication mechanism. Our job is to define these mechanisms and make sure they work, not to tell them that they made the wrong choice. I do think this could be a useful draft if framed as "So you've decided to use mTLS auth for DNS resolution". Helping operators to understand the risks, limitations, and strengths of mTLS in this context could be valuable. --Ben ________________________________ From: Tommy Jensen <Jensen.Thomas=40microsoft....@dmarc.ietf.org> Sent: Monday, July 22, 2024 7:52 PM To: Ben Schwartz <bem...@meta.com>; dnsop <dnsop@ietf.org> Cc: Damick, Jeffrey <jdam...@amazon.com>; Jessica Krynitsky <jess.krynit...@microsoft.com>; Engskow, Matt <mengs...@amazon.com> Subject: Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt Hey Ben, Thank you for reading the draft and your comments. I agree we would not need a draft for saying mTLS works as expected. This draft is saying something different: "mTLS is the way one should auth clients to encrypted DNS servers Hey Ben, Thank you for reading the draft and your comments. I agree we would not need a draft for saying mTLS works as expected. This draft is saying something different: "mTLS is the way one should auth clients to encrypted DNS servers for many reasons, cross-protocol use among them." The cost of doing something like "make OAuth or Privacy Pass work with DoT and DoQ" needs to be weighed against what benefits that would give over using mTLS that matter to the narrow use case where using client auth with encrypted DNS is appropriate (where both client and server are managed by the same authority, such as enterprise end-to-end). For example, you talk about "privacy properties" of PrivacyPass — which properties are you thinking about that would apply to the enterprise use case and be more useful than mTLS as a result? That's not a leading question, I legitimately don't know enough about PrivacyPass to know. Conversely, can you expand on the downsides of mTLS versus OAuth or PrivacyPass? If you would like to see a different recommendation, it would be good to understand why. If you disagree with the requirements the draft defined to based its reasoning on, that's a good place to start too (I note the markdown didn't survive the submission and the bulleted lists in the first two paragraphs of section 6 are not lists, sorry about that). Thanks, Tommy ________________________________ From: Ben Schwartz <bemasc=40meta....@dmarc.ietf.org> Sent: Monday, July 22, 2024 4:18 PM To: Tommy Jensen <jensen.tho...@microsoft.com>; dnsop <dnsop@ietf.org> Cc: Damick, Jeffrey <jdam...@amazon.com>; Jessica Krynitsky <jess.krynit...@microsoft.com>; Engskow, Matt <mengs...@amazon.com> Subject: Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt mTLS might be the most pragmatic approach today in many situations, but I don't think we can recommend it in the way that this draft would. It has some significant downsides, especially when compared against something like OAuth (which might integrate better with user account systems) or Privacy Pass* (which has much better privacy properties). It's true that these mechanisms can't be used with DoT and DoQ today, but it is within our power to fix that if we care to. If the only significance of this draft is today "mTLS works as you would expect for DoT, DoQ, and DoH", then I don't think we need a draft to tell us that. --Ben *I am a co-chair of PRIVACYPASS but I am speaking only as an individual participant.. ________________________________ From: Tommy Jensen <Jensen.Thomas=40microsoft....@dmarc.ietf.org> Sent: Thursday, June 27, 2024 2:41 PM To: dnsop <dnsop@ietf.org> Cc: Damick, Jeffrey <jdam...@amazon.com>; Jessica Krynitsky <jess.krynit...@microsoft.com>; Engskow, Matt <mengs...@amazon.com> Subject: [DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt Hello dnsop, Not to distract from the "should we deprecate DNS64" discussion I started after proposing updates to 7050, but this is the second draft (last one, I promise) I'll be proposing to this group as interesting work ahead of IETF 120. Joining me are co-authors Jessica from Microsoft and Jeff and Matt from Amazon. In light of enterprises increasingly using encrypted DNS for their own "Protective DNS" resolvers, we are proposing best practices for when and how to use client authentication with encrypted DNS. Since this is a Good Thing for enterprises who control both peers (stronger security for client policy application and security auditing post-attack) and a Bad Thing otherwise (privacy violations for the non-enterprises cases common to consumers), we feel there is a need to specify when implementors should or should not use it. 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<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-tjjk-cared-00.txt__;!!Bt8RZUm9aw!_8-BG_G6wHMcs_UVkwXqP0aVV9tQKSxtFZUsEClBxt2Mdmibw_KPRkiy1Bwe1ic3RrtchGlsJQRm-doecb78MhYiKeo$> Status: https://datatracker.ietf.org/doc/draft-tjjk-cared/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-tjjk-cared/__;!!Bt8RZUm9aw!_8-BG_G6wHMcs_UVkwXqP0aVV9tQKSxtFZUsEClBxt2Mdmibw_KPRkiy1Bwe1ic3RrtchGlsJQRm-doecb78334FWQc$> HTML: https://www.ietf.org/archive/id/draft-tjjk-cared-00.html<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-tjjk-cared-00.html__;!!Bt8RZUm9aw!_8-BG_G6wHMcs_UVkwXqP0aVV9tQKSxtFZUsEClBxt2Mdmibw_KPRkiy1Bwe1ic3RrtchGlsJQRm-doecb78WQDEe_U$> HTMLized: https://datatracker.ietf.org/doc/html/draft-tjjk-cared<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-tjjk-cared__;!!Bt8RZUm9aw!_8-BG_G6wHMcs_UVkwXqP0aVV9tQKSxtFZUsEClBxt2Mdmibw_KPRkiy1Bwe1ic3RrtchGlsJQRm-doecb78MUDB5QU$> 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
