Subject: Re: [dns-privacy] Call for Adoption: draft-hal-adot-operational-considerations

From: "Henderson, Karl" <[email-masked]>
Date: Tue, 20 Aug 2019 13:38:54 +0000

Hi Ben and Hugo,

I wanted to follow up and see if my response to Paul satisfies your concerns regarding ADoT being a new unspecified protocol?

To be clear, we argue that ADoT is NOT a new protocol. ADoT is simply DoT with a prepended A to disambiguate the path taken.

Regards,
Karl

>Hi Paul,
>
>To further clarify, we are not suggesting a change to the DoT protocol and are making liberal use of the final sentence in the Abstract of RFC7858 and echoed in the Introduction of RFC8310: "It does not prevent future applications of the protocol to recursive-to-authoritative traffic."
>
>Regards,
>Karl

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 Aug 2019 14:46:36 +0100

Hiya,

I'm not who you asked but...

On 20/08/2019 14:38, Henderson, Karl wrote:
> To be clear, we argue that ADoT is NOT a new protocol. ADoT is simply
> DoT with a prepended A to disambiguate the path taken.
Doesn't the need to figure out if an authoritative
server does/doesn't do DoT before sending a query
require something new that isn't in DoT and that
must be part of ADoT?

If so, ISTM that there is a new protocol spec of
some sort needed even if 90% of the meat of that
is the reference to DoT. (I guess maybe if the
answer for discovery was "does it listen on 853"
you could argue that's not new but I didn't think
the WG had figured that out yet.)

Cheers,
S.

---

From: "Henderson, Karl" <[email-masked]>
Date: Tue, 20 Aug 2019 13:54:30 +0000

Hi Stephen,

I agree we need a service discovery mechanism as specified in the considerations document. However, isn't this the same problem that both stub-to-resolver DoT and stub-to-resolver DoH face? If so, why do we accept these as protocols without this mechanism specified but we don't for ADoT?

Regards,
Karl

On 8/20/19, 9:46 AM, "Stephen Farrell" <[email-masked]> wrote:

    Hiya,

    
    
    Cheers,
    S.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 20 Aug 2019 11:58:59 -0400

On Tue, Aug 20, 2019 at 9:39 AM Henderson, Karl <[email-masked]>
wrote:

> Hi Ben and Hugo,
>
>
>
> I wanted to follow up and see if my response to Paul satisfies your
> concerns regarding ADoT being a new unspecified protocol?
>
>
>
> To be clear, we argue that ADoT is NOT a new protocol. ADoT is simply DoT
> with a prepended A to disambiguate the path taken.
>
>
>
> Regards,
>
> Karl
>
>
>
> >Hi Paul,
>
> >
>
> >To further clarify, we are not suggesting a change to the DoT protocol
> and are making liberal use of the final sentence in the Abstract of RFC7858
> and echoed in the Introduction of RFC8310: "It does not prevent future
> applications of the protocol to recursive-to-authoritative traffic."
>

I interpret that sentence differently.  I read that sentence to refer to
"future applications" of the [RFC 7858] protocol in the context of a future
standard, yet to be defined.  In the absence of such a standard today,
there is no defined way for a recursive server to speak DNS over TLS to an
authoritative server.

In your draft, I would characterize sections 3.1, 3.2, 3.3, 3.4, 3.7, 3.8,
and 4.2 (a majority of the substantive text) as input to the standards
development process for an ADoT standard, which is indeed part of this
working group's charter.  I think that this input is valuable, and will
help us develop a more useful, complete standard for ADoT.  However, I
don't think drafts whose main purpose is to provide input to the standards
process are generally appropriate for working group adoption.

I fully expect that this working group will define a standards-track
proposal for ADoT, with recommendations that cover the questions you've
raised in those sections.  I think readers might well be confused if both
that standard and this draft were to be published with RFC numbers.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 20 Aug 2019 12:15:48 -0400

On Tue, Aug 20, 2019 at 9:54 AM Henderson, Karl <[email-masked]>
wrote:

> Hi Stephen,
>
> I agree we need a service discovery mechanism as specified in the
> considerations document. However, isn't this the same problem that both
> stub-to-resolver DoT and stub-to-resolver DoH face? If so, why do we accept
> these as protocols without this mechanism specified but we don't for ADoT?
>

I think you've identified a key source of conceptual mismatch in this
discussion.

In my view, configuration of a secure transport for stub-recursive
communication is an entirely different problem from negotiation of a secure
transport in recursive-authoritative communication.  The crucial difference
is that, from the perspective of the DNS itself, a stub's recursive
resolver is configured "out of band" from the perspective of the DNS: the
stub does not learn its configuration through the DNS itself.  In contrast,
a recursive resolver learns about each authoritative server "in band",
through the DNS itself.

RFC 8310 provides usage profiles for client-recursive DoT as guidance to
DNS configuration systems, without regard to how configuration is
implemented.  From a DNS perspective, that's essentially all we can do,
because configuration is necessarily out of our hands.

A similar approach cannot be applied to ADoT.  Instead, we must define a
complete, secure, performant ADoT negotiation system inside the DNS.  Until
we have such a system defined, ADoT is not possible (except in limited
experiments).

Regards,

---

From: Christian Huitema <[email-masked]>
Date: Tue, 20 Aug 2019 09:30:06 -0700

> On Aug 20, 2019, at 9:15 AM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> A similar approach cannot be applied to ADoT.  Instead, we must define a complete, secure, performant ADoT negotiation system inside the DNS.  Until we have such a system defined, ADoT is not possible (except in limited experiments).

We have a working example of such transition: using the alternate service indication in HTTP to transition to HTTP 2 or to QUIC. The key there is to consider the problem as a transition from old and insecure to new and secure and to effect that transition over time. Perform a regular query over UDP or TLS, obtain additional information that DoT or DoH could have been used, remember that for next time.

Yes, that means that the first transaction is not protected. But then if we delay transition many more transactions are also unprotected. I like the idea of a progressive transition without disruption.

-- Christian Huitema

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 20 Aug 2019 13:04:34 -0400

On Tue, Aug 20, 2019 at 12:30 PM Christian Huitema <[email-masked]>
wrote:

> We have a working example of such transition: using the alternate service
> indication in HTTP to transition to HTTP 2 or to QUIC. The key there is to
> consider the problem as a transition from old and insecure to new and
> secure and to effect that transition over time. Perform a regular query
> over UDP or TLS, obtain additional information that DoT or DoH could have
> been used, remember that for next time.
>
> Yes, that means that the first transaction is not protected. But then if
> we delay transition many more transactions are also unprotected. I like the
> idea of a progressive transition without disruption.
>

I certainly agree that a progressive transition without disruption is
necessary, whatever mechanism we define.  However, I think this discussion
is not on topic for this thread, except as evidence that we have not yet
defined such a mechanism.

-- Christian Huitema