Apologies, I mixed up the drafts during my reviews.
(cut out the me being confused part)
---------- Forwarded message ----------
Date: Wed, 15 Sep 2021 15:31:25
From: Paul Wouters <[email protected]>
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
