Re: [dns-privacy] [Ext] Authentication in draft-ietf-dprive-opportunistic-adotq

[Eric Rescorla <[e-mail]>]

On Mon, Feb 15, 2021 at 2:59 PM Paul Hoffman <[e-mail]> wrote:

> On Feb 15, 2021, at 2:49 PM, Eric Rescorla <[e-mail]> wrote:
> > The reason we have WGs is to work out such matters in detail, no? And in
> particular, I think the WG should try to figure out the problem space
> before designing.
>
> Yes, please.
>
> > However, it seems like there's a relatively obvious strawman proposal
> here:
> >
> > - We invent some mechanism that allows you to specify in an NS record
> that the server takes TLS (as a hacky example, "servers have to be named
> <some-sentinel>.example.com").
> > - Servers are authenticated via the WebPKI, with the name as listed
> above.
>
> That addresses just one part of the problem space, the authentication of
> the authoritative server. Another part, which people have brought up a few
> times, is discovery (which is part of the first of those proposals, but not
> the second).


Yes, I agree there are two problems. This is one proposal in two pieces,
one for each problem.


Yet another is how a client of the resolver would determine if a lookup
> error means "the name doesn't exist" or "the name exists but the resolver
> was not able to get an authenticated answer".
>

I agree this has to be solved somehow, but I'm not really following why
it's that complicated. I'm not any kind of DNS expert, but I assume we can
invent a suitable error (SERVFAIL + extended error perhaps?).


> I'm sure there are plenty of things that people won't like about this
> (e.g., I imagine that some people would like to use DNSSEC), and the signal
> I just invented is gross. Maybe in the process of deciding what people
> don't like about this, we can understand the problem space better.
>
> The biggest one: which group of Internet users would want to use a
> resolver that will refuse to give useful answers if the answers aren't
> authenticated? Without understanding those users (as compared to a few
> people who would want to set up such a resolver), we can't evaluate such a
> design.
>

I'm not sure I follow. There are two situations here:

1. The server ostensibly offers DoX but I couldn't connect.
2. The server doesn't offer DoX at all.

In case (2) I would expect the resolver to proceed as normal. I.e., you
would get an answer. In case (1) I would expect it to return an error (see
above). I'm not aware of any particular reason to expect that users would
find these behaviors objectionable. After all, we already had a transition
in which the recursives decided to DNSSEC enforcement and that seems to
have gone reasonably OK.

-Ekr