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

[Brian Dickson <[e-mail]>]

On Tue, Nov 3, 2020 at 6:15 PM Paul Hoffman <[e-mail]> wrote:

> Greetings again. I really like many of the changes in
> draft-ietf-dprive-phase2-requirements-02 and think that it gets closer to
> what we want for requirements. One of the requirements seems unnecessary,
> however.
>
>    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).
>
> If the WG does with DoT and/or DoQ, you can discover the server's
> capabilities by probing port 853 and TBD-Q, or maybe by finding TLSA
> records. There is only a need to "publish" a list of secure protocols if
> they include DoH or DoHoQ.


No, this is not accurate, and highly misleading. I am not casting
aspersions on your intent, merely calling out the correctness of the
argument.

The prevention of downgrade attacks requires publication of servers
capabilities and intents, including prefered or offered protocols.
This includes DoT.

Counter-argument: an active attacker can force a downgrade by selectively
blocking port 853 queries.
If the secure transport for DoT is published, this becomes a
denial-of-service attack rather than a downgrade attack.
Lack of publication converts the blockage to a downgrade attack.

There may be multiple authoritative servers in different topological
arrangements, so that the attacker is on-path for only some of those
servers.
In that situation, blocking the port 853 queries to one server would result
in the client (resolver) attempting port 853 connections to the other
servers (assuming the non-opportunistic client).

The existence of clients and servers who both want to do encrypted
transport requires that the design accommodate that, notwithstanding the
desire for others to be opportunistic in their approach.
There is no way to have it both ways. Either strict client-server with no
downgrade is supported by the signaling or it is not.

The needs of the strict crowd cannot be ignored without failing to reach
consensus.
The strict requirements do not actually impose any obligation on clients
wishing to only do weak opportunistic with no DNSSEC validation or any
other non-verification type activity.
As you note, there is no way to force a client to validate.
I don't believe anyone is saying otherwise.


> Also, some folks on this list have already complained about added
> complexity of discovery mechanisms.
>

Please provide pointers or let them speak for themselves.
We should be discussing the requirements first, and addressing whether the
discovery mechanisms are too complex. Those may in fact be implementation
issues that might be addressed without impacting the high level
requirements.


>
>         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.
>

I think you are misreading what this paragraph says.

What it really says (or should say) is:
A given domain may have multiple authoritative name servers.
It may be the case that some of those name servers offer secure transport,
and others do not.
It may also be the case that some of those name servers do not offer
non-secure transport (i.e. regular port 53).
The method of publication of availability of secure transport MUST be
capable of distinguishing the availability of secure transport on a
per-authoritative server basis, and the (un)availability of non-secure
transport on a per-authoritative server basis.
I.e. ns1.provider-x.net may do DoT only (no port 53), and ns2.provider-y.net
may not offer any secure transport (only port 53), and ns3.provider-z.net
may offer DoH as well as insecure transport (so port 53 and port 443/DoH).
A client may be opportunistic, and choose any of the three, or may choose
to only use port 53 (thus only ns2 and ns3).
A second client may want to use strict security only, and may support DoT
and DoH, and thus use ns1 or ns3.
A third client may want to use strict security only, and may only support
DoT, and thus use ns1 only.

The choice of secure or not is always available to the client.
However, any client wishing to use secure-only MUST be able to detect and
prevent downgrade attacks. This places more limitations on publication,
naturally.
The server CAN know that a resolver appears to want to authenticate, if it
only offers secure transport and the resolver connects.
Not offering port 53 service in both its publication mechanism and in ports
that are providing DNS, is an unambiguous way of offering non-downgradable
service, should the client want to validate.

It matters what the server says it offers, as that is the only way to
prevent downgrade attacks from succeeding.


>
> This whole requirement could be dropped and it would not affect the
> security or availability of the desired service.
>

As Mark A would say, "This is wrong."
Well, technically, what the claim should be is regarding privacy, rather
than security. But it would still be wrong.
The only way to not affect the privacy, is to keep the requirement, and to
clarify the positive and negative elements of the publication scheme (i.e.
to say yes/no to port 53 in addition to optional yes to other secure
transports.).

It probably should be more detailed in tying the publication of supported
protocols to the name server names (and that the publication point would
need to be at or under those names), rather than in any way tied to a zone.
It is also worth suggesting that different capabilities can and should
require different names, even if the IP address of the server is the same.
E.g. ns1-strict-dot.nameserver-zone.example and
ns2-insecure.nameserver-zone.example for the same IP, with the former
indicating only port 853 should be used, and the latter indicating that
only port 53 should be used.
Then, the choice could be implemented at a zone level, by using NS records
of the former or the latter, as a signal for how that specific zone can be
reached by a client (modulo the client's desire to use secure transport if
it is available).

This is a bit complicated only in that it is multi-dimensional (multiple
DNS operators, possibly multiple jurisdictions with restrictions on
encryption, plus multiple zones per name server) and has a theoretically
large number of possible combinations.
However, in practice, any given zone will have a finite (and likely small)
number of name servers in its NS set (delegation and/or apex), and tying
the signaling on secure transport availability to the name server names is
an obvious choice that requires nearly no work or complexity on the
resolver.
The resolver has a policy that is either "don't want to use any encrypted
transport", or "might use it if the first one I check offers it", or "if
any secure transports are offered, I won't use anything less than a secure
transport".
>From that policy, the processing should be extremely deterministic.

And, for the most part, by tying the publication to name server names,
means that the chances of the information about secure transport not
already being cached is inversely proportional to the popularity of the
name servers themselves.
I.e. the  overhead associated this should become noise, based on the
log/log relationship on zone/server popularity and query volume.

Basically, this isn't difficult at all, IMNSHO.

Brian