Hi, > server and they were something between MTAs and users. So, imagine you're in > a public place and using WiFi and you want to check your email Did you read my full email? Thats EXACTLY what I wrote in a later paragraph. And it's the reason I wrote I vote for sha. And even would prefer iterations there %) And see the risk of rainbow tables used to reverse those.
> Disagree with your second sentence. If the purpose of hashing before was to > reduce the size of input values or provide collision free values Thats all the draft states. That the hashing was not intended as security feature. And that is true. If it would have been intended to secure the transmission, it would include iterations and possibly some anti-rainbow measures. I don't agree with this intention obviously, I was just stating that (only) for the purpose of harvesting addresses from the zone the hash of the localpart is not the thing to consider and it's also not helping much. And that was the main thing the authors were talking about there, stating that it's the job of the DNSSEC operator to secure the zone, not the OPENPGPKEY standard. Which is OK for me. I also don't say hashes are not useable for security functions - but a simple sha hash today also isn't the strongest one. One could even go as far and suggest scrypt or similar instead of chopped sha. So my main points are: - hash is better than base32 because it makes sniffing recipients from the network much harder - if we agree that it is a real problem, we should add iterations AND a SALT somewhere to the zone, or even switch to scrypt. It's also widely available in libraries today like for python or perl. But I have no idea how the others here see that and if it's worth delaying the draft even more. It would not be too complicated though and even doesn't have the DoS problems iterations have in NSEC3. I think the base32 transmition will actually prevent people from using for example a thunderbird plugin that looks up keys - for privacy reasons. I expect a normal hash would be OK for most of those though, after all the metadata is not uber-secret, it's still in all the mail server logs on the way and so on. Real paranoid people will wait another 20 years for encrypted DNS to be widely deployed %) But sending all your recipients in clear text really is not what you want today... > Furthermore, you have to consider in future the internationalized email > addresses That's where the proposal of normalizing the unicode comes from. And as far as I remember there were no objections to this so far, it's just not in the draft yet. Greetings, Florian -- [*] 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
