Re: [dns-privacy] [Ext] Requirements for authoritative server preferences

[Paul Hoffman <[e-mail]>]

On Nov 4, 2020, at 12:37 AM, Stephane Bortzmeyer <[e-mail]> wrote:
> 
> On Wed, Nov 04, 2020 at 02:15:03AM +0000,
> Paul Hoffman <[e-mail]> 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