Hello Ben (and Warren), On Tue, 2021-06-08 at 11:09 -0400, Ben Schwartz wrote: > Hi DPRIVE, > > A few years ago(!), Warren Kumari proposed a hacky way to signal ADoT support > by choosing a special nameserver name [1]. Since then, folks have proposed a > ton of different ways to indicate ADoT support, making use of the nameserver > name, DS record fields, or new RR types. > > Warren and I recently revisited that old idea, and felt that it might fill a > gap in some of the active proposals, so we reworked it into a new proposal > (intended status: experimental) that better matches the WG's adopted drafts.
a lot of ideas have been thrown around over the years, and most of those were not discussed well because they were not written down in drafts; a lot of goalposts were moved without having clear pictures of the full scope of several ideas. So, thank you for typing this one in so we can discuss it! I also much appreciate Appendix A which summarises several other proposals very succinctly and explains which bits this draft does better compared to those. Obviously, and the draft mentions this, this is a terrible terrible hack. But that's no reason to hate it. It matches some of the use cases better than "cleaner" solutions. The encoding with the single letters is neat. Tying it to SVCB, at least to have familiar well defined terms to explain what the letters do, makes sense to me. I note that there are no further words on actual SVCB records. I can imagine combining your draft (a quick, immediate signal that causes encryption without waiting for an SVCB lookup, be it synchronously or asynchronously) with actual `_dns` SVCB records as described in other recent drafts (the adox draft, and my and Paul's -common draft). Further down this email the reasons for that should become clearer. Paul disagrees with me on tying your explanation to SVCB, and says: "a resolver operator does not need to implement this as part of SVCB. Also, it isn't really SVCB because it is default-port only, and it doesn't handle any other SVCB extensions. It should be called "aext--" instead, and scrub any SVCB parsing ideas." He also brings up the chance that the signals in this label might disagree with the signals in the SVCB record, so untying it from there will cause less consternation and still have the same semantics. Going through the draft bit by bit, here are my thoughts (based on discussion with several other people): Abstract: definitely agree that parent side SVCB is unlikely to make sense, ever. Background: 'synchronous binding check' - Paul and I of course proposed an asynchronous one, which avoids the latency hit, but it means less communication will be encrypted. We don't feel that this is an "interim" solution because we don't think parent-side SVCB is likely to ever come, or be very useful if it both unsigned and rarely available. We propose that this be the actual, long-term solution. Flag form: proposal: drop this, and allow resolvers to query for SVCB always. That way, outdated parent side information only 'hurts' for a short while. It also makes clear that resolvers who really want to know about the signals can maybe get a signed SVCB back from the child. Menu form: 'first label' - we not see why this would be a requirement. As an example, TSIGs requirement to be the last record in a DNS packet made writing the XPF draft harder than should be necessary. Demanding to be leftmost hinders future expansion. As we discovered with xn--, it is essentially easy to look for specially-tagged labels anywhere in a name. QUESTION: do we need more than 36 codepoints? Answer: we don't think so. (If we do, we can create another foo-- label form.) QUESTION: should we be able to encode svcparams? Answer: the current candidates for that are, I think, 'port' and 'dohpath'. We don't think we need them, particularly if there are SVCB records in the child. Implementation requirements: says 'MUST also support adox', and that makes sense if the WG treats this as an interim solution; but we are not not optimistic. In DNS protocol terms, we don't think parent side SVCB has any significant benefits over this proposal anyway. Security Considerations: authenticated NS names etc. etc. - yes, this proposal will not deliver authenticated encryption (but neither will parent side SVCB). The text above the question is clear on the tradeoff. Operational considerations: no comment on the existing text, but there is another concern that was also brought up around DOTPIN. As A.4 mentions 'creates challenges during TLS key rotation', there is a very similar challenge, and that is 'the auth operator wants to get rid of DoT' (or DoQ or whatever) - and its smaller sibling, 'the auth operator really wants to move from DoT to DoQ because it is so much lighter on resources' or whatever. Because delegation NSsets are a zone property, an auth operator does not have full control over what is signalled for their servers. It can, of course, remove svcb--dotq.ns1.example.com from the example.com zone, but then anything delegated to that name just breaks. Proposal: allow resolvers to downgrade (in contradiction with the current second half of section 5). Then say: if svcb--t was ever signalled, the auth operator promises to at least send TCP RST for any connection attempt to port 853. Similar for DoH (443) and DoQ (the QUIC protocol has a CONNECTION REFUSED error code). This way, the downgrade in a resolver can be swift, instead of having to wait for timeouts. - Peter van Dijk & Paul Hoffman _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy