b) is the most practical solution, I don't know ANY mail provider or private mailserver that handles local parts case-sensitive...
a) would be more correct. And I would suggest an additional DNS record for "rules", like TXT="nodots,lower,subaddressing:+" for Gmail (I hope it's correct) and maybe just "lower" for most others. The mail provider can publish this rule, and clients that want to help the enduser can apply it to the local part before querying for the OPENPGPKEY/SMIME record... The only drawback is that you need 2 DNS queries, but does anybody notice these additional 50ms? And the most used "rules" can be cached or hardcoded into the client. With this you are most flexible, you don't have unwanted collisions, and it's a solution that can be fully automated and secure for encryption gateways. You even could think about a "domain-salt" that could be added to the "rules" TXT record, so that "info" in domain.com is not the same as "info" in domain.org... Then an attacker needs a rainbow table per domain, and not one global rainbow table... c) is no option (privacy) Michael On 02.09.2015 02:14, Brian Dickson wrote: > 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
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
