On Nov 4, 2020, at 12:37 AM, Stephane Bortzmeyer <[email protected]> wrote: > > On Wed, Nov 04, 2020 at 02:15:03AM +0000, > Paul Hoffman <[email protected]> wrote > a message of 114 lines which said: > >> 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 in recognition that some servers for a domain might use a >> secure transport protocol and others might not. >> >> It is impossible for a server to tell whether a resolver is authenticating, >> so being able to say "you must authenticate" is kinda just posturing. The >> choice of whether or not to connect should always be with the resolver. >> Further, if a resolver is using a mechanism that requires strict >> authentication, it truly doesn't matter what the authoritative server has >> said it wants. > > Nevertheless, hints from the authoritative name server can be useful, > such as "You should use DoT in strict mode but there is also a DoH > service which is quite experimental with a self-signed > certificate".
Such hints could indeed be useful. I don't see them as a requirement, particularly if that requirement delays increased privacy or, worse, makes it harder to deploy. > Other IETF protocols have such hints from the > authoritative side about what the client should do, even if they > cannot be enforced (RFC 7208 for instance). SPF is an excellent example of a protocol that has made things more fragile while intending to make them more secure. > Is it worth the complexity? I don't know but it is not useless. Fully agree. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
