On Thu, 3 Sep 2015, Petr Spacek wrote: note if you meant this as a comment for the IETF LC, you should use that threat over at [email protected] and not this one.....
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 don't think anything helps against moderately-funded attackers. How long does it take to build a dictionary of common email names/varients ? As the nsec3 cracker shows, it's going to be a simple offline attack to generate the qname's, then you go online to fire them off.
Personally I would store salt+iteration parameters in "_openpgpkey.<domain>" so the whole tree can be shared/DNAMEd at will.
That would cause an additional administrative burden though. Now one cannot just "add OPENPGPKEY" record to the zone. Now you have to query for the salt before you can generate and then add the OPENPGPKEY record to the zone. And whoever updates the salt record now needs to ensure to update all existing OPENPGPKEY records. so in theory you would have to: 1) query the salt 2) generate the openpgpkey record 3) give it to whatever human/webui adds it to the zone 4) requery the salt to ensure it hadn't changed 5) keep querying the salt to see if you need to submit an updated record That's a lot of overkill and someone (google) can still simply lookup the salt and run it over strings like "paul" and compare it with the DNS query log.
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.)
That's even more state. And you still have the case where the salt record is there but no OPENPGPKEY record for paul is there, and you end up possibly requerying for paul many times anyway. That is, it does not really solve the problem. Only a small part of it.
- 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.
when does "raising the bar" become "denial of service"? Especially when the nation states have more CPU power than we do :P
Really, I think that we should rethink the hashing if we are serious about privacy.
The real answer here is DPRIVE plus using a trusted DNS resolver. Which solves query privacy in general and is not specific to one record type. Paul _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
