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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]