Hello Brian, many thanks for a completely worked-out protocol. Please find some comments below. A further reading of the document might yield more comments, but this is what I have now after my first reading.
On Fri, 2021-09-17 at 20:48 -0700, Brian Dickson wrote: > Status: > https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-auth/ > Html: > https://www.ietf.org/archive/id/draft-dickson-dprive-adot-auth-02.html > Htmlized: > https://datatracker.ietf.org/doc/html/draft-dickson-dprive-adot-auth > Diff: > https://www.ietf.org/rfcdiff?url2=draft-dickson-dprive-adot-auth-02 Quotes below are from the document. > NSECD New OPT RR N Signal desire for NSEC(3) for [RFC8198] I do not understand what this does that the DO bit does not already do. > Use of DS records [I-D.dickson-dnsop-ds-hack] for the protection of the > delegation to the authoritive name servers Of course, Ben's DSGLUE would work here too. The key differences between ds-hack vs. ds-glue appear to be: * hashing vs. verbatim * NS records only vs. flexibility (with NS/A/AAAA and possibly TLSA as good starting points) I prefer DSGLUE, but as far as I can see it would be a drop-in replacement in your protocol. > Use of "glueless" zone(s) for name server names' zone > [I-D.dickson-dnsop-glueless] I see how this is a relevant part of how your setup fits together, but I don't like this requirement, and I believe using DSGLUE instead of ds-hack would remove this need, and allows dropping -glueless from the set of documents. > This would allow DNS caching to avoid repeated queries to the authoritative > server for the zone containing the DNS server names, to obtain the TLSA-type > information. This is not true for the example zone data given. The ns1-4 A/AAAA records would prevent expansion of the wildcard for the TLSADOT record. The same problem appears with DNST in section 6.3.1. Given that, having DNST as an alias for SVCB, and TLSADOT as an alias for TLSA, seems mostly pointless to me. (That said, svcb-dns defining that '.' maps to _dns.ns1.example.com, not ns1.example.com, is very inconvenient to operators. The dot form is basically useless in svcb-dns. So, in that regard, I do like DNST.) > The value "Force" indicates the server should attempt to use ADoT, and return > a failure code of XXXX and an EDE value of YYYY if the authoritative server > does not offer ADoT, or any other ADoT failure occurs. 'the authoritative server' is too handwavy. Can 'Force' even work until all TLDs have encryption? I'm not sure I like section 8 at all. It feels like encoding policy at the wrong layer. Conclusion: ignoring TLSA for a moment, this protocol appears to be just a few changes away from my/Paul's proposal (if I generously include ds-glue-or-similar in that). It is very good to see this variant written out, so that it can be judged at its merits, which has been hard for various handwavy proposals only seen in messages in email threads. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
