Hi Benno, Alex, and Jason. I have a few comments and questions about this version. Hopefully these are helpful.
DW > 5. Requirements > > The requirements of different interested stakeholders are outlined > below. > Perhaps this is obvious others, but I would like to see a better explanation of exactly what kind of requirements these are meant to be. Are they implementation or protocol requirements (versus operational requirements)? Or requirements of some other type? Also, I'm struggling a little bit with "interested stakeholders" above. I don't think these are requirements *on* stakeholders. Maybe it would be better to say something like "[protocol] requirements of different elements are outlined below."? > 5.1. Mandatory Requirements > > 1. Each implementing party should be able to independently take > incremental steps to meet requirements without the need for > close coordination (e.g. loosely coupled) If that is a requirement then MUST/must instead of "should"? > 2. Use a secure transport protocol between a recursive resolver and > authoritative servers > > 3. Use a secure transport protocol between a recursive resolver and > TLD servers > > 4. Use a secure transport protocol between a recursive resolver and > the root servers These were worded a differently in an earlier version. The following text is from draft-lmo-dprive-phase2-requirements-01: > 2. Implement DoT between a recursive resolver and single level domain > authoritative servers (high risk, high priority) > > 3. Implement DNS privacy protections between a recursive resolver and > TLD servers (low risk, low priority) > > 4. Implement DNS privacy protections between a recursive resolver and > the root servers (low risk, low priority) I get why DoT was changed in #2, but why was "DNS privacy protections" changed to "a secure transport protocol"? Why were the risk and priority classifications removed? Also, I'm not sure how these are requirements as written (e.g., they lack RFC 2119 key words). And, on whom or what are these requirements placed upon? > 5. The secure transport MUST only be established when referential > integrity can be verified, MUST NOT have circular dependencies, > and MUST be easily analyzed for diagnostic purposes. > I think the "MUST NOT have circular dependencies" requirement should be further explored (i.e., more text). Since item 9 below says that specification of preferences must occur using DNS only, is that itself a circular dependency? Also, could more be said about the "easily analyzed" part? "easily" might be subjective, unless there is to be some way to quantify this requirement? > 6. Use a secure transport protocol or other DNS privacy protections > in a manner that enables operators to perform appropriate > performance and security monitoring, conduct relevant research, > etc. Again, not sure how this is a requirement or for whom it is a requirement. Does it mean something like "use of secure transport protocols MUST NOT prevent operators [of xxx] from performing appropriate performance and security monitoring, conducting research, etc."? > 7. The authoritative domain owner or their administrator MUST have > the option to specify their secure transport preferences (e.g. > what specific protocols are supported). This SHALL include a > method to publish a list of secure transport protocols (e.g. > DoH, DoT and other future protocols not yet developed). In > addition this SHALL include whether a secure transport protocol > MUST always be used (non-downgradable) or whether a secure > transport protocol MAY be used on an opportunistic (not strict) > basis. > > 8. The authoritative domain owner or their administrator MUST have > the option to vary their preferences on an authoritative > nameserver to nameserver basis, due to the fact that > administration of a particular DNS zone may be delegated to > multiple parties (such as several CDNs), each of which may have > different technical capabilities. Including that some servers for a domain may use secure transport and others may not? It is common for a given name server to be authoritative for multiple zones. Should this document state that a name server can provide secure transport for one zone but not another? > 9. The specification of secure transport preferences MUST be > performed using the DNS and MUST NOT depend on non-DNS > protocols. > > 10. For the secure transport, TLS 1.3 (or later versions) MUST be > supported and downgrades from TLS 1.3 to prior versions MUST not > occur. > It seems like #10 should be qualified with something like "For TLS-based transports..." since there might be some future secure transport that is not based on TLS? > 5.2. Optional Requirements > Optional Requirements is perhaps an oxymoron? Maybe "Recommendations" of some kind? > 1. QNAME minimisation SHOULD be implemented in all steps of > recursion > > 2. DNSSEC validation SHOULD be performed > > 3. If an authoritative domain owner or their administrator indicates > that (1) multiple secure transport protocols are available or > that (2) a secure transport and insecure transport are available, > then per the recommendations in [RFC8305] (aka Happy Eyeballs) a > recursive server SHOULD initiate concurrent connections to > available protocols. Consistent with Section 2 of [RFC8305] this > would be: (1) Initiation of asynchronous DNS queries to determine > what transport protocols are supported, (2) Sorting of resolved > destination transport protocols, (3) Initiation of asynchronous > connection attempts, and (4) Establishment of one connection, > which cancels all other attempts. > To me this item about happy eyeballs feels out of place in this document, and I worry that we are not fully aware of the amplification effects that can occur from multiple layers of happy eyeballs. For example, user clicks on www.example.com URL. Happy eyeballs browser looks up both A and AAAA records (maybe more with new stuff like HTTPS & SVCB). Happy eyeballs recursive sends queries to both IPv4 and IPv6 addresses of name server. That’s 2x2=4 queries for the single click. Now add secure transport happy eyeballs and it becomes 2x2xN for however many secure transports are given. IMO this needs further study and discussion before recommending it.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
