[dns-privacy] A Few More Suggestions for the Requirements Draft

["Hollenbeck, Scott" <[e-mail]>]

I have a few more suggestions for draft-ietf-dprive-phase2-requirements. In Section 5.1:

After the current requirement #7, I'd like to suggest adding a requirement like this to make it clear that the authoritative name server determines if server authentication is required, or not:

"The authoritative domain owner or their administrator MUST have the option to specify whether server authentication is required for all secure connections to the server."

After the current requirement #9, I'd like to suggest a requirement like this to help make it clear that it's possible to the different name servers hosting a zone to have different secure connection requirements, and a recursor needs to be able to adapt appropriately:

The recursor MUST have the option to vary its connection behavior on an authoritative name server to name server basis. 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 in recognition that some servers for a domain might use a secure transport protocol and others might not.

I'd like to propose a slight modification to number 10. An implementation may have an internal specification of preferences for its own purpose. For instance, a transport preferences cache. Access to that cache wouldn't require use of the DNS, so I think it makes sense to note that the requirement for DNS use is for access by others:

OLD
10. The specification of secure transport preferences MUST be performed using the DNS and MUST NOT depend on non-DNS protocols.

NEW:
10. The specification of secure transport preferences, when published for access by other parties, MUST be performed using the DNS and MUST NOT depend on non-DNS protocols.

I think we need to add a normative reference to RFC 8446 in the current #11:

OLD:
For secure transports using TLS, TLS 1.3 (or later versions) MUST be supported and downgrades from TLS 1.3 to prior versions MUST not occur.

NEW:
For secure transports using TLS, TLS 1.3 ([RFC8446] or later versions) MUST be supported and downgrades from TLS 1.3 to prior versions MUST not occur.

Do these seem reasonable? I'll close with a question: we've talked about server authentication, but not about client authentication. We should say something in the requirements draft about client authentication, but right now I'm not sure of what makes the most sense. OPTIONAL, REQUIRED, something else?

Scott