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

[Erik Nygren <[e-mail]>]

See also Tim April's draft for an SVCB-based NS2 record:

https://tools.ietf.org/html/draft-tapril-ns2-01

It has quite a bit of similarity to this latest draft, but differs in a
number of ways
based on a bunch of discussions we had last year to refine something that
worked well with common operational models and DNSSEC.

I'd be interested in seeing something that was a convergence of Tim's NS2
draft
and this draft from ekr.  (Tim who thought about this lots last year will
hopefully
jump into this conversation later this week.)

     Erik






On Sat, Feb 27, 2021 at 12:51 PM Ilari Liusvaara <[e-mail]>
wrote:

> On Thu, Feb 25, 2021 at 01:25:25PM -0800, Eric Rescorla wrote:
> > 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.
>
> I still think that there should be new RRTYPE that lives in nsname node
> and carries service info. Putting it anywhere else means it can get out
> of sync. Not that it is fully coherent even then, but at least one could
> get rid of most coherence issues.
>
> > > 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.
> > >
> > The document is intended to be agnostic about WebPKI versus TLSA. Can you
> > point out what makes you think it favors it?
>
> I also read the document as seemingly preferring WebPKI (through not
> explicitly saying so).
>
> My views of using WebPKI being a very bad idea have not changed:
>
> - WebPKI does not support service scoping.
> - WebPKI fundamentially relies on DNS authoritatives, causing circular
>   dependency if used for DNS recursive<->authoritative communications.
> - WebPKI has the rootstore mess.
> - Using WebPKI would cause issues to both DNS system and WebPKI itself,
>   due to change mismatch.
>
> > 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.
>
> All the possibilities of relation between child, parent and nsname are:
>
> 1) Nsname is in child zone
> 2) Nsname is in descendant of child zone.
> 3) Nsname is in parent zone
> 4) None of the above.
>
> - Cases 1) and 2) need glue.
> - Both 1) and 4) are common.
> - gTLDs look to be limited to either 2) or 4).
> - ccTLDs can do whatever they want, and at least some do 1).
>
> And it is the nsname node that currently carries the IP addresses of the
> nameserver (A/AAAA records).
>
> And it is not obvious to me that contacting nameserer in the clear to
> obtain its encrypted transport information (in case child is
> authoriative for its nsname) blows the cover: There is no obvious to
> me way to tell if it is in-zone nameserver or out-zone nameserver of
> another zone. And I consider nsnames as blown anyway.
>
>
> > > 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.
>
> I think that allowing signaling DoH versus DoT and DoH3 versus DoQ is
> unnecressary, as DoH(3) seems to only bring complexity over DoT/DoQ,
> seemingly without any significant benefits. And I consider already the
> complexity of DoQ scary.
>
> - The traffic stands out like sore thumb due to endpoints involved.
> - Without server push, DoT and DoH have the same capabilties: out-
>   of-order request-response on stream transport.
> - Server push is effectively dead, and the only thing it would add is
>   allowing sending negative responses without DNSSEC (with suitably
>   advanced resolved). But it would be easy to add capability to send
>   negative responses to DNS, and such capability would be useful outside
> - Similarly, without server push DoQ and DoH3 have the same
>   capabilities: full out-of-order request-response. Not sure if HTTP/3
>   has server push, but if it does, what it adds would be the same as
>   in HTTP/2 case.
>
> There may be need for simpler transport optimized for low resource use,
> only intended for transporting DNS QUERY messages and their responses.
>
> > > 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
>
> The kinds of credentials I see as possibly useful:
>
> - No credentials (oppurtunistic-only)
> - Server will staple its credentials with DNSSEC chain/signature.
>   (there should be only one mechanism for this, e.g. subset of
>   draft-dukhovni-tls-dnssec-chain).
> - Hash of server hostkey.
> - Hash of self-signed root certificate.
>
> And there is obviously issues with trusting values if this information
> is not protected with DNSSEC, including the case where records are sent
> as glue, as glue is never signed.
>
>
>
> -Ilari
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>