On Thu, Dec 13, 2018 at 04:21:39PM -0500, Daniel Kahn Gillmor wrote:
> Hi Mukund--
>
> thanks for your prompt followup!
>
> On Fri 2018-12-14 02:22:12 +0530, Mukund Sivaraman wrote:
> > 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.
>
> ah! good call, thanks. so a "trailing-=-stripped b32 encoding" would
> work OK, right?
>
> I did the generation in python with:
>
>
> base64.b32encode(hashlib.sha256(rawdata).digest()).decode('us-ascii').strip('=').lower()
>
> it's not hard to re-add the = padding before re-decoding, based on the
> length of the string, which will be a fixed length.
Nod that'd work. :)
> > 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.
>
> i think i disagree. for one thing, we've talked about the ability to do
> opportunistic connections even in the absence of a signal. so for
> nameservers located within extremely huge zones, they might just have to
> rely on opportunistic connections. But in practice, even for a
> nameserver that *serves* a huge zone, its name doesn't need to be in the
> zone.
>
> Let's look at this from another angle: what sorts of limits are we
> talking about here?
>
> https://tools.ietf.org/html/rfc1035#section-2.3.4
>
> establishes the limits, in particular:
>
> labels 63 octets or less
> names 255 octets or less
>
> so we're saying that the terminal label will consume 57 octets (52 for
> the b32, 4 for "dot-", and 1 for the dot). this means that the zones
> that can contain such a label are limited to 198 octets.
>
> The longest name in the public suffix list (https://publicsuffix.org) is
> 41 octets (without the trailing dot):
> s3.dualstack.ap-northeast-1.amazonaws.com
>
> so even any long-named zone within that longest public suffix still
> leaves 157 octets for the intervening sub-zones -- space remains for
> more than two full-length 63-octet labels.
>
> So i'm not worried -- there will be other problems with long domain
> names long before we hit this one.
I don't think this way. :) I think it will not support every RFC 1035
DNS name, but only a subset of it. It should work for every valid name,
because they are valid names and some application may want it. Why
settle for hacks when it can be designed elegantly?
> > Nod, that may work too (how does one get the key then?)
>
> you get the key by connecting to the server and receiving it as part of
> the server handshake.
Nod. (can't help thinking that's another roundtrip, but perhaps that
can't be avoided.)
> > If it can be demonstrated to work for near-future algorithms (next 2-3
> > decades), then it's fine.
>
> i don't think anyone knows yet what the acceptable algorithms will be in
> 25 years. We can guess of course, but as the saying goes: prediction is
> hard, especially about the future.
That's not what I meant to say.. I'll explain. The NIST competition is
happening now and there'll be a "winner" soon, and there are many
choices of algorithms being proposed now. The system should be designed
to accomodate such algorithms, so that it will not be obsolete in the
next 2 decades *based on what we expect/know now*. It should be able to
accomodate perhaps this NIST competition "winner" that we currently
expect will be secure 20 years from now.. not some algorithm chosen 2-3
decades from now.
> > 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.
>
> sure, but i don't want to future-proof it out of existence. :) sometimes
> too much complexity added too early on a what-if basis can kill a
> protocol as easily as an unforseen change that does eventually happen.
Nod, I agree.
Also I'm just pointing out various items that need to be considered,
that's all. If it works fine with all that, then it works fine. +1. :)
>
> > 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.
>
> I appreciate your enumerating these concerns. I hope my analysis is
> helpful in giving some sort of reassurance that they're not a problem
> for this sort of scheme.
>
> --dkg
> _______________________________________________
> dns-privacy mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dns-privacy
Mukund
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
