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

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Feb 2021 21:27:33 +0000

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 23 Feb 2021 18:52:47 +0000

> -----Original Message-----
> From: dns-privacy <[email-masked]> On Behalf Of Paul
> Hoffman
> Sent: Monday, February 22, 2021 4:28 PM
> To: [email-masked]
> Subject: [EXTERNAL] [dns-privacy] Complete changes to the (no longer just)
> opportunistic ADoT draft
>
> 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.

[SAH] Very basic first question: we do not yet have a finished requirements document for exchanges between recursive resolvers and authoritative servers. I understand the enthusiasm for an opportunistic ADoT draft, but how does the group intend to make sure that it remains in synch with the requirements draft?

Scott

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 23 Feb 2021 14:30:59 -0500

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 <[email-masked]> 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.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Feb 2021 19:59:12 +0000

On Feb 23, 2021, at 11:30 AM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> I really want fully authenticated ADoT but I have significant concerns with this draft.

As do the authors.

> 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 authors felt backed into doing this because none of the strong proponents for fully-authenticated encryption were willing to write a draft, yet we were required to make our proposal interoperate with that proposal. As I said in my message yesterday, if the WG hates the idea of a single draft with both use cases, we are happy to back out the changes as soon as someone writes a draft that we can then match our protocol to.

--Paul Hoffman