Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>

["John R Levine" <[e-mail]>]

One other issue that hasn't come up is the security model, in particular 
what it means for a domain to publish PGP keys that it claims are 
associated with mail addresses in that domain.

The draft's introduction compares this design to existing key servers and 
argues that the key servers refusing to delete keys for which the private 
keys have been lost is a problem to be solved, although the key servers 
consider it to be a security feature.

In sections 1 and 7, it claims that finding a key through DNS lookup is 
not a substitute for web-of-trust verification, which is fine.  But 
section 5.2 says that if a domain publishes a key for an address that's 
inconsistent with an existing key, verification of the key is "treated as 
a failure."  It's unclear what the effect is supposed to be, but 
considering the discussion of the lost key problem, it appears that the 
intent is that the sender would stop using the old key.

Maybe a domain is an investment advisor ensuring that it can log its 
employees' mail, or maybe it's webmail that wants to snoop on its users to 
add intrusive advertising.  Unless a sender has external knowlege of the 
relationship between a domain and its mail users, a can of worms that I 
wouldn't want to open, this is in effect a downgrade attack.

PGP has always associated keys with users and put users in control of 
their keys; the inability to delete lost keys from keyservers is an effect 
of that. This draft moves a lot of that control to domain operators. That 
may or may not be a good idea but it's a large change to the security 
model.

R's,
John