Forwarded, since this is also discussed on this list now. ---------- Forwarded message ---------- Date: Wed, 15 Sep 2021 15:31:25 From: Paul Wouters <[email protected]> Cc: [email protected], [email protected] To: IETF Secretariat <[email protected]> Subject: Re: [Add] The ADD WG has placed draft-schwartz-svcb-dns in state "Call For Adoption By WG Issued" On Tue, 14 Sep 2021, IETF Secretariat wrote:
The ADD WG has placed draft-schwartz-svcb-dns in state Call For Adoption By WG Issued (entered by Glenn Deen) The document is available at https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/ Comment: A Call for WG adoption is being made for DRAFT-SCHWARTZ-SVCD-DNS by the ADD Chairs.
I think I missed previous discussion about this. I'm a little surprised at the call for adoption, so apologies if this reply comes late. I believe this draft is not the best idea. It basically copies a lot of "unsigned" data to turn it into a "signed" copy. The more obvious approach would be to just provide a signature over the unsiged data in the new DS variant record, which would reduce a lot of complexity. A parent that wishes harm, eg wants to modify the unsigned data it has, would be caught either way. A non-parent (forwarder in the middle) should have no chance to forge anything to begin with because it should require the child version of the NS RRset anyway, and thus already can authenticate by checking existing DNSSEC signatures. I am also not sure about the encodings here. It is not wire format and it is mostly not presentation format. Why introduce a new format? Section 4 contains a special DS record to disable DANE? I am not sure I understand how and more importantly, where this works. If this is about the child zone, then perhaps we should not give the parent zone the power via DS records to make such statements about the child zone. Eg a nation state could globally disable DANE by adding these special DS records for all its delegations. It would be much better to encode some SVCB style record into DS and have a child CDS record that can be used to confirm the child's intent. Section 5 says to not use DSGLUE without DNSSEC, but one has to wonder what the gains are. If it can be used to find a more secure transport, even without dnssec, why not? As the alternative is to not use the record and use plain old insecure DNS with no known trust anchors anyway? It seems the IETF processes around encrypted DNS keep walking around the elephant in the room. A few extra RTTs for privacy that focuses on unrealistic privacy gains on in-baliwick nameservers TLS connection. If you want real privacy gains from encrypted DNS, you have no choice but to group yourself onto large DNS hosters anyway, and then the fact that your reveal to talk to the large hosters DNS nameserver is a moot point. This is all way too much complexity for no real operational benefit. Paul _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
