Hi, I have done quite some research on DNSSEC zone security, NSEC and NSEC3 enumeration, attacking various zones using a GPU cluster and similar things, so I think I can judge the relevant attack vectors quite well...
And indeed, there are various things to consider. In the result I am currently in strong favour of SHA instead of base, and I know of people who think base32 will make the standard much less attractive at least here in germany where privacy is a big topic - and for PGP users in general, as I expect they use PGP for a reason... We should not forget: the question is not only, if providers will publish keys for their zones, but also if clients will adopt the standard and query those keys. Both has to happen for the standard to be a success. But first my answer to: > >I would see the use of base32 (without extra improvement > >techniques) as a security risk. This is because, it decreases the > >entropy of SHA256 hash function > The planned/suggested use of base32 is *instead of* SHA256. Thus, > entropy is not a topic - as there is no hashing. I think Hosnieh was referring to the SHA256 done in the NSEC3 records, and/or the danger of harvesting the emails from the DNS. The current draft in 6.2 notes, that Email addresses "are not secret" and The hashing is not a security feature. I don't fully agree on the first sentence, but the rest is true. And also the solution: if you are worried about zone walking, using and adjusting NSEC3 or similar counter measures (white lies) is the answer, not a different input encoding. NSEC3 uses iterations and you can adjust how many (various things have to be considered there, but that's nothing special of this draft but normal DNSSEC operation) - so if there is one SHA-step more ore less to be done on the local part will add very little on the attacker side. So using base32 will NOT decrease security here in any way relevant in real life. Of course, if you use NSEC (like fedoraproject did for their openpgpkey test deployment) base32 is much worse than chopped sha - but it you are concerned about your zone data, simply don't use NSEC. So @Hosnieh: cosider using zone walking counter measures matching your paranoia level, and the SPAMMER issue should be gone. But there is a second side to consider: the DNS requests of the people sending mail. And there we (currently) don't have a (widely deployed) solution to hash or encrypt those on a DNS level. That means using base32 the emails of recipients I am sending mails to will go in clear text over the wire. And that's not good. Today many emails including their metadata at least in germany are fully encrypted from the sender to the recipient (not end to end, but on every segment) - SMTP submission using TLS and verified cert, intra-server SMTP with opportunistic TLS (vulnerable to MitM, but secure against passive attacks), IMAP with TLS and verified cert on the receiving end. And especially sending and receiving end is where pratical snooping is often possible, especially also active MitM. That means you can use your laptop in a cafe, your tablet in a hotel, and even without a VPN you can be pretty sure people around don't snoop on your mail communication. With OPENPGPKEY+Base32 deployed, they would see for EVERY mail you send the recipient in clear text. Even for the (currently 99.x%) cases, where the recipient doesn't have an openpgpkey record(!). Yes, one iteration of hash isn't a very good protection, especially for simple formed adresses. But still it is MUCH harder to snoop than clear text. Meaning: the NSA (and I with my GPU cluster) sniffing your Hotel WiFi will be able to unhash 80+% of your recipients. But the guy sitting on the table next to you with his cool $0.99 hacker-app for android or some guy fireing up wireshark for fun won't, unless he has a good rainbow table which unfortuneately (unlike for NSEC3) is pratical there. Still: attacking a hash is something completely different from simply sniffing a clear text. I have spoken to people who are really concerned by this and won't be enthusiastic about deploying this standard when it sends adresses in clear text through the net. Personally, from a privacy point of view, I'd also prefer to even see some form of iterated hashing implemented (having a record in the zone telling how many iterations or something like that), but I understand that this would be a completely new topic making things even slower, what do others think? So: a strong vote from my side to stay with chopped sha256. I still think the advantages of base32 are more theoretical and people who really want to use these advantages will have to implement own responders - if you're willing to do that you also could implement a webfinger service or similar. The OPENPGPKEY standard for DNS should be a simple way to publish the keys of your zone, and the current 03 draft provides that. Adding some paragraph about handling UTF8 (normalize, don't touch otherwise) and it's good to go. Greetings, Florian P.S.: On a side note: yes, lowercasing also weakens the attack surface of the hash. But not much, as unlike passwords the positions in which you uppercase an email are pretty obvious in real life. But actually, after many discussions with people actually using PGP regularly, I would even prefer to drop the lowercasing (possibly allowing the client to try it as second guess - will be done anyway) over using base32. -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstrasse 15, 81669 Muenchen Sitz der Gesellschaft: Muenchen, Amtsgericht Muenchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
