Hi Daniel
First, thank you for replying. I wondered if I'd said something
completely wrong. :)
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.
> > 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.
> 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?) If it can be
demonstrated to work for near-future algorithms (next 2-3 decades), then
it's fine.
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.
> > 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.
Mukund
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
