On Tue 2018-12-11 11:08:06 +0530, Mukund Sivaraman wrote: > 1. The RDATA of an NS record has to be a hostname, so it would limit the > amount of data that can be encoded within the NSDNAME. As an example, > base32 encoding is not possible.
why is base32 encoding not possible for a hostname? just for fun, i've stood up a new server. It's not a DoT server, but its name follows the guidance at: https://knot-resolver.readthedocs.io/en/latest/modules.html#experimental-dns-over-tls-auto-discovery https://longname.cmrg.net/ https://dot-fvyrmqvxe2yeialcpsu7xlbs6xefgd5rsa6mjwycewdrpeq2jcaq.nameservers.cmrg.net/ i had no trouble getting a certificate issued for it, and no problem pointing NS records to the same name either (it's not running an authoritative DNS server there, so it isn't fully connected, but that has nothing to do with the name. So the length of the name, and its ability to contain a base32-encoded SHA256 digest is not an issue. > 2. It would have to work for nameservers that are within a domain with a > very long name already. what are the length limits that you're concerned about? if we make a system that works for all nameservers that are within zones that are up to (for example) 100 octets, that would be a huge win. Remember that we're also talking about the nameserver's name itself, not the zones it can serve. so even longer zones can still work, as long as their nameservers aren't in-bailiwick. > 3. Let's assume it takes about 10 years for resolver->auth privacy > transport to trickle into widespread operational availability. It is > expected that quantum computers capable of obsoleting traditional crypto > will be available in as few as 15-20 years from now. It is unclear if > the limited length of keys that can be encoded into a subset of a DNS > name would be sufficient for post-quantum crypto algorithms. 15 years ago, quantum computers were also 15-20 years away :) I share your concerns about key length and post-quantum resistance, and i wouldn't want to design a system that can *only* work with short keys. However, at least one of the weird-naming-proposals on the table (the knot-resolver experimental work above) is just stuffing a fixed-length sha256 digest there -- that digest can cover PQ key material too. If the concern is an attack on sha256 itself, then we should think about other ways to plan. > 4. NS records returned as part of delegations are unsigned, so for a > resolver to trust key information in the RDATA of such NS records in a > delegation, it would require the delegation to be returned using secure > transport to the parent-side nameserver of the zone cut. During last > night's conversation, there was some talk about fallback to plain > transports - it will not be useful unless the entire delegation from > root is followed with secure transports. I agree with you that there is a security gap here, as with most steps of indirection. But i'd temper the "will not be useful" a little bit -- maybe "will not defend against active attackers on first connection" is more accurate? At any rate, the NS record could itself be DNSSEC-signed, and a suitably-cautious client could ask the server for its own NS record and associated RRSIG (QNAME-minimized, of course) before asking for anything else. Does this address your concerns about the feasibility of encoding (hashes of) keys in nameserver DNS names? --dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
