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.
> 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.
> 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.
> 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.
> 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.
> 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
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
