On Thu, Feb 25, 2021 at 01:25:25PM -0800, Eric Rescorla wrote: > On Thu, Feb 25, 2021 at 1:10 PM Paul Hoffman <[email protected]> wrote: > > > On Feb 25, 2021, at 12:44 PM, Eric Rescorla <[email protected]> wrote: > > > > On Thu, Feb 25, 2021 at 12:15 PM Paul Hoffman <[email protected]> > > 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 [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
