Re: [dns-privacy] Complete changes to the (no longer just) opportunistic ADoT draft

[Ben Schwartz <[e-mail]>]

I really want fully authenticated ADoT but I have significant concerns with
this draft.

As Paul notes, this draft is so different from the previous draft that it
covers effectively a new problem space.  This is surprising for an adopted
document.

The draft states the authenticated use case as follows:
> The use case in this document for fully-authenticated encryption is
> recursive resolver operators who want to prevent on-path attackers
> from impersonating authoritative servers for zones for which the
> resolver is sending queries.

Unfortunately, the draft does not achieve this goal:
1. Because it only checks for TLSA records asynchronously, the first
queries to an uncached nameserver will always be in cleartext.
2. Within the current text, an attacker could simply drop any TLSA
responses, ensuring that they never reach the cache.  The resolver will
then send cleartext indefinitely.
3. An attacker could replace the parent's NS glue record with their own
name, so that the TLSA query goes to _853._tcp.attacker.example.

Additionally, I think this draft raises serious operational concerns, by
enabling "doomed" configurations.  Suppose "ns.customer.example" is an
alias for "ns.cloud.example".  If "ns.cloud.example" starts supporting
ADoT, the customer can place a TLSA record at
"_853._tcp.ns.customer.example".  This will provide the customer with
working authenticated ADoT ... until ns.cloud.example changes its
configuration (e.g. a key rotation months later), at which point the
customer's zone will become instantly inaccessible to authenticating
resolvers.

I think we can, and should, solve all of these problems, but doing so in a
way that is widely applicable, easily deployed, and latency-efficient in
the common cases is a very tricky project that has inspired half a dozen
highly creative drafts so far.

In my view, this proposal is too early, incomplete, and carries significant
risk.  It's possible that we will ultimately produce a solution that is
compatible with this approach, but that seems far from certain to me.

On Mon, Feb 22, 2021 at 4:28 PM Paul Hoffman <[e-mail]> wrote:

> Greetings again. You probably just saw the announcement of
> draft-ietf-dprive-opportunistic-adotq-01. After the discussion on the list
> about us having to make the opportunistic draft track the (unpublished)
> fully-authenticated draft, Peter and I decided it would be easier for the
> WG to keep both ideas in their heads by making a single draft that covers
> both opportunistic and fully-authenticated ADoT.
>
> Thus, the new draft his titled "Recursive to Authoritative DNS with
> Encryption" because it covers both use cases and the process for both types
> of resolvers. (Clearly, we should change the draft's filename after the
> draft submission window opens again in two weeks.) We tried hard to make
> the protocol description as short as possible by not repeating steps that
> are the same for all resolvers, but also to clearly differentiate when
> something is different.
>
> The changes are so massive that the diff is useless; you have to read this
> as a new document.
>
> This is just a first attempt at a combined-use-case document. There are
> certainly holes, and probably places where people will want to change the
> protocol for their preferred use case. (Of course, if people hate the idea
> of a single document, we can do another version of this that just covers
> the opportunistic use case, and proponents of the fully-authenticated use
> case can use it as a template for their work.)
>
> One obvious set of changes we will ask the WG about is adding DoQ
> throughout. In our structuring of the new document, we don't think that
> will be too disruptive.
>
> Please review and comment. Please remember that this is a very early
> version and is not meant to be complete now, but we will certainly want it
> to be so over the course of many months.
>
> --Paul Hoffman_______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>