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

[Ben Schwartz <[e-mail]>]

On Tue, Aug 20, 2019 at 9:54 AM Henderson, Karl <[e-mail]>
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,
> Karl
>
> On 8/20/19, 9:46 AM, "Stephen Farrell" <[e-mail]> wrote:
>
>
>     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.
>
>
>