On Sun, Mar 31, 2019 at 05:48:21AM -0700, Watson Ladd wrote: > Dear all, > Please rip these ideas to shreds: > 1) An extra bit in a response for "you could have asked over TLS"
Seems vulernable to downgrade attacks. And seemignly leaves obtaining the authentication data as open problem. > 2) An extra field when looking up the nameserver for "you can ask > that server over TLS" > 3) An extra field/bit/convention for "this nameserver supports tls" > (like tls-ns vs ns) There are only two records that live on parent side of zone cut, namely NS and DS (then sometimes one sees "glue" A/AAAA records, needed to break chicken-and-egg problem if nameservers for zone are inside zone itself). NS is AFAICT not signed, and can only contain hostname of the nameserver. There are some nasty hacks that code the key into this name, but those suffer from variety of issues (problems with "cloud" DNS provoders[1], difficulty of rolling keys, etc...). DS is signed, and has algorithm field. Supposedly unknown algorithms are ignored, but there are buggy nameservers out there that break if all DS entries have unknown algorithm. And turns out abusing DS records also runs into issues with "cloud" DNS provoders. Adding another RRtype with needed magic properties would take Standards Action (as expert review requires RRtype not to be magic) and then updating parent nameservers to be able to deal with the RRtype (since it can not be generically handled). And trying to add extra fields to NS or DS is sure to cause horrible borkage. One could possibly hack around the "cloud" problems by adding yet another RRtype (that is not magic from DNS data model perspective) that lives under the nameserver name and contains the final keys (and adding an optional layer of indirection). Adding records at child side of cut has its own issues, namely that retroactive authentication can be annoying to implement, and it is more difficult to make the thing work without full DNSSEC chain (glue records, if parent supports that?). -Ilari _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
