Good day, uta WG, We have updated our draft to address several comments from participants across multiple WGs. That said, I will specifically call out where have only partially addressed or rejected with an explanation why. Also, apologies to you both, as I managed to omit you from the acknowledgements because I was filling in off the list of things we (think we) addressed. I will fix that in the next revision.
Reviews are welcome! We are seeking adoption here per IESG guidance for WG selection, so don't hold back please. I will separately invite the dnsop community to contribute here given the obvious overlap in interests. [Eliot] > 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? Probably not surprising, but we deemed deprecation of a not-rarely used encrypted DNS protocol to be out of scope for this document. Recognizing multiple encrypted DNS protocols then keeps us convinced of the need for mechanisms that work agnostic of the transport the encrypted DNS traffic is using. On a personal note, I would oppose deprecating DoT because while I understand the value of solving problems exactly once, I would argue DoH and DoT solve a different subset of challenges that justifies their independent existence. Some deployments cannot tolerate the (not large, but non-zero) overhead imposed by HTTP even with the no cookies and minimal headers approach, while other deployments cannot tolerate identifying their traffic as DNS by using port 853 and making the traffic more readily identifiable as not-HTTP even when over 443 to machine learning. [Neil Cook] > 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. We agree that there are scenarios where different servers (identified by IP address and name tuple rather than name alone) have different functionality. Our point here is to separate server-imposed policies (example: enterprises having different resolution policies for different contractors or organizations who need to prove their identity and know they must do so in advance) and client-imposed policies (example: as a client, I choose to use Awesome DNS Service, a public set of resolvers, for malware and ad blocking but not parental controls). We feel this text is still necessary to do that to avoid justification of practices where Awesome DNS Service authenticates users in the name of determining the difference when auth is entirely unnecessary by presenting different IP addresses for each behavior. That said, related to this and other feedback on the document being too prescriptive, we also added Section 9.1 to cast this document as recommendations for maximizing interop between unrelated implementations but not defining protocol violations when they are not followed by deployers who know their circumstances require other reasoning. For example, if Awesome DNS Service is otherwise a public resolver, they should not introduce auth in the name of informing users they connected to the wrong endpoint because that forces deanonymization when the service is supposed to be publicly available anyway. However, if Awesome DNS Service is already a paid service who needs to enforce server-side policies (i.e. some resolutions for customers and none for non-customers), then the situation is different as it isn't just client-selected policies now. Authentication in that case makes more sense and then at that point a malware-filtering endpoint could reject connections with some communication that "you didn't pay for this, go use the ad blocking service you paid for" (though as a recommendations-only document, we don't define ways of doing that). Does this expounding on the existing text and the addition of Section 9.1 address the spirit of your concern, Neil? Thanks, Tommy -----Original Message----- From: [email protected] <[email protected]> Sent: Monday, April 14, 2025 10:45 AM To: Jeffrey Damick <[email protected]>; Jessica Krynitsky <[email protected]>; Joe Abley <[email protected]>; Matt Engskow <[email protected]>; Tommy Jensen <[email protected]> Subject: New Version Notification for draft-jaked-cared-01.txt A new version of Internet-Draft draft-jaked-cared-01.txt has been successfully submitted by Tommy Jensen and posted to the IETF repository. Name: draft-jaked-cared Revision: 01 Title: Client Authentication Recommendations for Encrypted DNS Date: 2025-04-14 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/archive/id/draft-jaked-cared-01.txt Status: https://datatracker.ietf.org/doc/draft-jaked-cared/ HTML: https://www.ietf.org/archive/id/draft-jaked-cared-01.html HTMLized: https://datatracker.ietf.org/doc/html/draft-jaked-cared Diff: https://author-tools.ietf.org/iddiff?url2=draft-jaked-cared-01 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 -- [email protected] To unsubscribe send an email to [email protected]
