Hi, I have reviewed this draft. I have some questions and feedbacks...
>The sense of the room in the IETF-93 meeting was to do do a BASE32 encoding of >local part with 60 character labels, shortest label is the left most label. 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 (As far as I know based on my experiment with SHA256, SHA256 are case sensitive) which result in possible attacks on usernames and forging usernames. Unless they use the same techniques that is used for DNScurve key hashing. < https://en.wikipedia.org/wiki/DNSCurve > . But if they use this technique then the size of the message is no longer 32 because in that technique for characters that does not have any base32 value, they use the combination of characters that already exist in base32. As a simple example, for lower 'a' that is not in base32, they use 'AB'. In other word, the size of the 28 bytes hash value is no longer 32, but it is around 51. But if the the same technique as DNScurve is used, it is better than base64 because base64 also doesn't support all characters that exists in the result of SHA256. Furthermore, I also do not understand the reason why in section 3 they are converting the result to lowercase. This doesn't affect the SHA256 result. Since the username in email is always lowercase, it make sense to do this lowercase process before encoding to UTF-8 because the assumption is that the email address is always lowercase. Therefore, converting UTF-8 result to lowercase just decrease the entropy of SHA256 function. Then allows attacker to easier proceed with dictionary attack because it can just skip many inputs values for SHA256. This means, with this approach the probability of collision for SHA256 increases. So, in my opinion, before having any decision, the authors need to bring some analysis of base32 and base64 and lowercase, uppercase and SHA256 and share the analysis so that to be clear how much security risk it might provide for email users. <snip> should already be encoded in UTF-8 (or its subset ASCII). If it is written in another encoding it should be converted to UTF-8. Next, it is turned into lowercase and hashed using the SHA2-256 [RFC5754] algorithm, </snip> Thanks, Best, Hosnieh _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
