Re: [dns-privacy] [Ext] New draft on authenticated recursive <-> authoritative

[Eric Rescorla <[e-mail]>]

On Thu, Feb 25, 2021 at 1:10 PM Paul Hoffman <[e-mail]> wrote:

> On Feb 25, 2021, at 12:44 PM, Eric Rescorla <[e-mail]> wrote:
>
>
>
>
> On Thu, Feb 25, 2021 at 12:15 PM Paul Hoffman <[e-mail]>
> wrote:
>
>> The idea of doing discovery in a new type of glue in the parent seems
>> interesting. For the unauthenticated use case, it potentially removes a
>> round trip, and doing so is quite valuable. If the WG likes the idea of
>> new-glue-type-in-parent, Peter and I can add it to the draft covering
>> unauthenticated ADoT to keep the two use cases in sync.
>>
>> Question: why does this draft use an SVCB record instead of a TLSA record
>> for that new glue? The only advantage I see is that SVCB can indicate the
>> DoH template, but the WG has so far not shown interest in DoH over DoT.
>
>
> There are (at least) three reasons:
> 1. Semantically, TLSA does not mean "I support TLS", but rather "if you
> are to do TLS, do it this way. SVCB means something different.
>
>
> Fair point. However, given that we get to say what a particular usage of a
> particular RRtype is, that is not fatal.
>

No, because there are existing deployments, so we can't just retcon the
meaning.


> 2. It's not clear that the certificate binding properties of TLSA are
> desirable in the glue in this case, for a number of reasons, including the
> "getting out of sync" problem that Ben Schwartz pointed out, and the
> possibility that  we will want to use WebPKI.
>
>
> OK. From the wording about authentication in the draft, I figured you
> would actually want DNS-based public keys, even with the general problem of
> TLSA and getting out of sync.
>

The document is intended to be agnostic about WebPKI versus TLSA. Can you
point out what makes you think it favors it?

In any case, it's quite different to have the TLSA records in the parent
and in the server, because the server can ensure they don't get out of sync
with itself in a way that is harder than with the parent.


> 2. SVCB does not just let you signal DoH versus DoT it also allows you to
> signal DoQ, which has obvious advantages.
>
>
> TLSA also lets you signal DoQ. If it didn't, we would have rejected it out
> of hand.
>

I think it depends what you mean by "signal". TLSA can signal the
certificate which is to be expected for a QUIC connection, but AFAICT it
has no way to indicate that the server supports QUIC, whereas with SVCB you
can do this with ALPN (h3, doq). Your draft has a TODO here, so I'm not
sure what you have in mind.



> In addition, if it becomes necessary to signal what kind of credentials
> the server has. SVCB has a natural way to add that.
>
>
> Well, you said that in your draft, but I don't see that as a possibility
> in Ben's draft. It could be added, but there is no extension mechanism
> there.
>

Huh? You just define a new SvcParamKey:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-03#section-14.3

-Ekr