ietf
[Top] [All Lists]

RE: Summary of IETF LC for draft-ietf-dane-openpgpkey

2015-09-15 15:42:35
On Tuesday, September 15, 2015 12:43 PM, Stephen Farrell wrote
On 15/09/15 20:33, Dave Crocker wrote:
On 9/15/2015 12:26 PM, Stephen Farrell wrote:
Note that I am not addressing what I think is an underlying objection
which I interpret as "this won't work and is hence a bad idea." I do
think folks can validly propose an experiment like this for a feature
(e2e email security) we've never managed to get deployed at scale. (By
"like this" I mean something with lots of associated and non-crazy
concerns.) Were it the case that running this experiment would break
a bunch of things I would feel differently but I don't think that is
the case.


Arguably, a failure of this mechanism could be quite serious.

... 
It seems very unlikely to me at least that this experiment would
do significant harm.

There is a recognized risk, that publishing lists of email addresses in a 
public server might enable phishing and spam. This is why some people propose 
using salting or robust hashing, e.g.:

   P. Spacek, [2] 20150903
   - hashing not good enough for privacy, suggests salting.
     SF: response was that salt means an odd DNS transaction, which
     seems a valid response to me, also that hashing isn't meant to (and
     won't) get strong privacy, but still marginally preferred by WG to
     non hashed LHS.

This is pretty much the only area where "significant damage" could occur. I 
suppose that it will be mitigated by the response to the WGLC.

If there is information indicating serious breakage is in fact a
non-negligible likelihood that would indeed be interesting.

I think that having the experiment is appropriate. There is actually a big 
question about the basic idea behind the draft, publishing *users'* key in the 
DNS domain of the *server*. Currently, there is no requirement that users 
provide their server with a copy of their public key, and often no process for 
doing so. The experiment will tell us if this a deployment blocker, or not. If 
it is not, then we have a solution. If it is a blocker, then I would expect the 
Open PGP WG to propose an alternate mechanism.

-- Christian Huitema