I think the safest choice is a). Here's the logic that applies to a) vs b), which I think leads to choice a) being preferred. Suppose there is a domain where email addresses are case-sensitive. (RFC822 et al permit this.) Suppose there is a case-folded collision (two LHS addresses differ only by case).
What happens if you want to encrypt ONLY to the correct recipient? You need some way to identify the correct public key from among the two (or more!) colliding LHS values, or you are forced to encrypt with all the keys found. This is an undesirable security and/or privacy risk introduced by the use of str2lower. Or, alternatively, how do you associate the correct key with the correct recipient, in a way that does not also leak the non-SHA256'd address to a passive observer? I don't think you can. These questions are mooted in choice a), since there is no case folding and thus no collision. So, I think the choice between a) and b) is a no-brainer: a). Brian On Tue, Sep 1, 2015 at 2:44 PM, Olafur Gudmundsson <[email protected]> wrote: > > Dear Colleagues > > We received some questions about the selection. > In the discussions on the different ways to represent the left hand sides as > DNS names there are number of ways the three ways we have been discussing are: > a) HEX( SHA256( LHS) [:28])) i.e. 28 left most bytes of SHA256 hash hexified > b) HEX( SHA256( str2lower(LHS))[:28]) i.e. the same as before but the email > name is lower cased before digesting, this will help mainly email addresses > written in Latin-1 > c) split_lables(HEX(LHS), 60)) i.e. encode the email as a HEX, there are > two drawbacks and one advantage see below > > a) and b) both are fixed length and fit in one label, c) on the other hand > may require multiple labels > c) in theory allows server that sees query may apply rules that allow it to > give out better answers > c) on the other hand also has privacy issues against a passive “attacker” > i.e. one that only listens to traffic, it can w/o any work discover email > addresses, a) and b) require work by attacker to discover the email address > (reverse/guess the HASH()) . There was pushback due to the privacy issue. > > The difference between a) and b) is the lower casing. While this may be a win > in some cases that is unproven, as we do not know if more people will know or > guess the LHS they want to send to. > In addition the DNS contains a simple facility to equate names i.e. CNAME. > > Olafur & Warren > > > > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
