On Dec 13, 2018, at 12:52 PM, Mukund Sivaraman <[email protected]> wrote: > > On Thu, Dec 13, 2018 at 01:50:39PM -0500, Daniel Kahn Gillmor wrote: >> 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? > > The first and last octets of each label in a hostname must be an > alphabet or digit (first specified in RFC 952 and relaxed in RFC > 1123). The other octets of the labels can be alphabet, digit or > hyphen(-). > > As an example, for a 32-octet value that's sent through base32: > > [muks@naina ~]$ echo -n "abcdefghijklmnopqrstuvwxyz789012" | base32 > MFRGGZDFMZTWQ2LKNNWG23TPOBYXE43UOV3HO6DZPI3TQOJQGEZA==== > > The trailing '='s are part of the base32 encoding. > > [muks@naina ~]$ echo -n > "MFRGGZDFMZTWQ2LKNNWG23TPOBYXE43UOV3HO6DZPI3TQOJQGEZA====" | base32 -d > abcdefghijklmnopqrstuvwxyz789012[muks@naina ~]$ echo -n > "MFRGGZDFMZTWQ2LKNNWG23TPOBYXE43UOV3HO6DZPI3TQOJQGEZA" | base32 -d > abcdefghijklmnopqrstuvwxyz7890base32: invalid input > > This will not validate as a hostname label.
That's only true if you use Base32 naively. If you know that you are always encoding a 256-bit value, you can drop the padding characters. >>> 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. > > Exhaust all the size of a DNS name except for a few characters and > imagine a nameserver belongs under that zone. A scheme has to work and > well for all extremes of DNS, not only a subset. That is not true for names that are targets of NS records. That is, if you want one or more of the nameservers for X to be able to use the cryptographic naming scheme, that name does not need to be under X: it can be under a more reasonable-length name. Again: these are optional extensions, not mandatory for name service. > >> 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. > > Nod, that may work too (how does one get the key then?) There are many ways to get a key and then compare the hash of the key with the hash you get securely from the DNS. > If it can be > demonstrated to work for near-future algorithms (next 2-3 decades), then > it's fine. SHA-256 is not near-future: it has been deployed for well over a decade. > It is over 13 years since RFC 4035 and DNSSEC is still not in widespread > use. Features take time to be adopted and so if the proposed protocol > will need revision to make it support another algorithm, then it'll take > as many years from that time to be available, so we should future proof > it a bit. 256-bit hashes do not need to be "future proof": they are well-established. 256-bit keys do not need to be "future proof" either. >>> 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. > > Maybe.. I am just pointing out the issues. Perhaps there's some benefit > in signing them and the address glue anyway, to stop resolvers from > going off on wild chases due to some kinds of poisoning. NS records are signed; is is only the glue records that are not. The names being discussed here are in the NS records themselves. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
