On 9/23/15 9:00 PM, John R Levine wrote: > I should have been clearer, the assertion is "this is my user's key". > >> Let's focus on the case where it's completely false, yet it's still >> reasonable to trust the domain to publish the right MX records. I'm not >> seeing that case at all, so I'd appreciate some help. > > A straightforward example is that the mail system, through malice or > outside pressure, does an MITM attack on users who have their own > keys, so it publishes a key it controls and re-encrypts mail on the > way through to the user's own key. An outsider who had the old key > might notice that the key changed, or if he didn't have the old key, > probably not. > The good news is that this should be observable by the user. That is, he should be able to query the domain for his own public key and compare. But there are many corner cases. One might be if a parent zone hijacked the entire domain; sent mail as the user and sent mail as some set of that domain's users, causing them to think that a communication was trusted. Assume this happened because the parent got hacked. That could be mitigated by a warning from a client to a recipient that the keys have changed, but we know how well warnings work. Is this any worse than a CA being hijacked? You yourself argued to me on this list some time ago that it is, at least in part, because all of this is tied to a single-rooted hierarchy. But for an experiment, it might be fun to see how these sorts of bugs could be kinked out (or if they can be). Eliot
Attachment:
signature.asc
Description: OpenPGP digital signature