I think one should combine: 1. Whatever the left hand side is in the traditional RFC822 envelope address
2. Case folding, so that it is surviving whatever basic matching in email clients/services 3. Hash, if nothing else for privacy reasons So, I guess (b) is the closest, but I want to be more specific it is "the ascii/fallback" version of the local part and not (for example) the internationalized version -- while supporting potential future UTF-8 encoded raw addresses. I.e. use whatever localpart is used in the SMTP protocol. But I guess that is what you mean with LHS? Patrik On 1 Sep 2015, at 20:44, Olafur Gudmundsson 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
