Hi, > From: dane [mailto:[email protected]] On Behalf Of Florian Kirstein > Hi, >
> 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... +1 > 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. This is one of my major concern. But there is other privacy problem that is during transmission since before, these keys are not queried from a DNS 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 and send an important email. It is enough that someone sniff all queries to DNS server and just gather these values. If it is base32 without any hashing, then this adversary can easily gather information as only convert it back to utf or other encoding is enough. If it is hashed then do dictionary attack offline and gather all these email addresses. (doesn't need to be online too). So this means that if before, the adversary had hard time to gather these information by checking all websites or mailinglists. Now it is not true and by only sitting back while sniffing public wifi he can fetch a lot of such information and do reverse step to return to return it back to the victims' emails. Of course, if it is hashed, we complicated his life and he need one more step. > 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. Disagree with your second sentence. If the purpose of hashing before was to reduce the size of input values or provide collision free values, this is not the only use case for that anymore. One example, Passwords are hashed and kept in databases. If it is not for security reason and it is not to mitigate plain text attack on the database or storages, then it appears that I am not understanding the reason!? Another example is that hashing public key in some mechanism to increase the strengthen of public key that is not only related to the strengthen of public cryptography algorithm and key size but also involve the strengthen of SHA function. You can find plenty of mechanisms, even at IETF, that uses this method. > > Adding some paragraph about handling UTF8 (normalize, don't touch > otherwise) and it's good to go. I had some discussion about this with some of my colleagues. It makes sense to do that step because each implementation might use different encoding for email addresses. In other word, the value for Java might be different than .net. So I am not disagree with that step and I think it is a right step to do. Furthermore, you have to consider in future the internationalized email addresses if and if the DNS registrar accepts to have internationalized domain (e.g. a domain name in German) . So, in that case it makes sense again to do this step. Best, Hosnieh _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
