Hello, as far as I can tell people favor various LHS-hashing variants for privacy reasons. Assuming that this observation is correct, I consider current hashing scheme totally insufficient - it does not protect anyone's privacy against even against moderately-funded attackers. We should do better (not only to please Snowden :-) I very much like the generic idea of salting described in variant a) here: https://mailarchive.ietf.org/arch/msg/dane/LuC7BYtd6zVEWJF0s4cnmBLL1rU (I'm not so certain about "rulez", but that is a separate discussion. Do not conflate these two discussions.) Personally I would store salt+iteration parameters in "_openpgpkey.<domain>" so the whole tree can be shared/DNAMEd at will. Yes, this requires additional lookup. Still, I can see important benefits which in my eyes outweigh the disadvantage: - The additional "salt" lookup works as privacy guard for domains which did not deploy _openpgpkey at all. If the client does not find "salt" record then no lookups for names derived from LHS should be made. This effectively prevents leaks for domains which did not deploy _openpgpkey. (Domain name leaks anyway because of MX lookups.) - The "salt" record for big mail providers will be often in a nearby cache so the additional time-overhead for big mail providers will be negligible. And of course, TTL for this kind of record can be pretty long. - Salt/iteration count can be increased over time so we can keep raising the bar to make it costly to revert the hashing as computing power gets cheaper. Really, I think that we should rethink the hashing if we are serious about privacy. Petr Spacek On 28.8.2015 17:11, The IESG wrote: > The IESG has received a request from the DNS-based Authentication of > Named Entities WG (dane) to consider the following document: > - 'Using DANE to Associate OpenPGP public keys with email addresses' > <draft-ietf-dane-openpgpkey-05.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2015-09-11. Exceptionally, comments may be > sent to iesg@xxxxxxxx instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. _______________________________________________ dane mailing list dane@xxxxxxxx https://www.ietf.org/mailman/listinfo/dane -- Petr Spacek @ Red Hat