Hello Paul, Paul Hoffman wrote: > Wearing my author hat: I don't care between b32 and hashing. Both are > equally easy to document. However: > > On 5 Aug 2015, at 4:28, Stephen Farrell wrote: > >> So sorry to continue an argument but shouldn't this experiment be >> a more conservative about privacy just in case it ends up wildly >> successful? > > How is using the hash more conservative about privacy, except in zones > that are signed with NSEC instead of the more common NSEC3? If you > assume zones signed with NSEC3, both options are equally susceptible to > dictionary-based guessing attacks, given that the effort to create > search dictionaries for the billion of common LHS names is pretty low > even for hashes. >
for OPENPGPKEY/SMIMECERT zones, operators could (maybe SHOULD) use NSEC/NSEC3 "narrow" signing to prevent "zone-walking". The issue is more in the DNS query logs. My experience from working with many DNS-admins over the last decade tells me: DNS-Admins that could/would snoop into DNS-query logs by creating a small Perl script to decode the email addresses seen in the logs. Less DNS-Resovler Admins would go all the way of breaking hashes either using dictionary-based guessing attacks or a rainbow table. Breaking hashes requires much more "willful intent" than decoding BASE32. The hashing communicates a "don't go here" message, even though it is technically not a strong protection. It is like having a closed door vs. no door at all. No door communicates "come in, no secrets, we're open" while the closed door (even if it can be opened by minor force) communicates "private space". Best regards Carsten
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
