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