[messaging] The Simple Thing

Ben Laurie ben at links.org
Sat Oct 4 03:26:43 PDT 2014


On 3 October 2014 22:35, Joseph Bonneau <jbonneau at gmail.com> wrote:

> Let me try to summarize this thread (as I understand it) since I've been
> lurking and I think there may be some connections between ideas missing.
> Here's an attempt at outlining how MITM detection would work in two
> discussed cases as I understand it:
>
> CT-style (I think we should call it CT-style to avoid confusion with
> Certificate Transparency proper for TLS certificates)
>

Yeah, I think this is a good idea.



> *Alice looks up Bob's key.
> *The Evil Log inserts a spurious key for Bob. We're assuming (I think
> almost all of us are willing to assume this) that log-consistency auditors
> ensure the log has to actually put the spurious key into a globally
> consistent log forever. Trying to locally fork Alice's view is too risky if
> some non-zero proportion of users gossip out of band.
>

Then this is really the Evil Keyserver doing the inserting. Evil Logs would
presumably try other tactics...


> *Later on (after up to the MMD) Bob gets a ping from his monitor that "a
> new key for Bob has been logged." Bob concludes that the Evil Log is evil.
> Alice learns nothing.
>

Don't forget the existence of an MMD is tradeoff - the original version of
CT required a log inclusion proof to be served alongside the cert. It would
be possible to do that for this (the price is new keys take longer to
generate).

Also, Alice could also watch the log for keys she holds changing. So, Alice
can certainly learn that they key has changed, too.


>
> The Simple Thing
> *Alice looks up Bob's key. Two versions seem to have been discussed at
> different points:
>      Version (a)-Alice gets it directly from Bob over an untrusted channel.
>      Version (b)-Alice gets it from a semi-trusted key directory/service
> provider for Bob's address.
> *In Version (a), a MITM simply changes Bob's transmitted key. In Version
> (b), the Evil Directory signs a spurious key for Bob and returns it to
> Alice.
> *Ideally, Alice asks Bob out-of-band if this new key is correct before
> sending anything. If so, Bob detects the attack and warns Alice not to send.
>

If there's this magical non-MITMable out-of-band channel, why is Alice not
using it to send the message to Bob in the first place?


> In Version (b) Bob furthermore concludes that the Evil Directory is evil.
>
> The assessment is that CT-style allows only the recipient to detect the
> attack, after the fact, and The Simple Thing allows the sender to detect
> the attack before sending. To me this wasn't the most intuitive summary-in
> both cases it's only the intended recipient (Bob) who can be certain an
> attack took place and that the Evil Log or Evil Directory has been evil.
>
> The difference is whom you need to be "paranoid" (or just perceptive). The
> Simple Thing detects attacks if the sender is paranoid and actually insists
> on preemptive fingerprint checks and CT-style detects attacks if the
> recipient is paranoid and has monitoring alerts set up and actually checks
> them.
>
> "Being paranoid" means slightly different things of course: setting up
> monitoring vs. doing fingerprint checks. Without hard data we can't really
> be sure, though intuitively it seems to me that setting up monitoring and
> checking against your own recent activity is probably easier. For one
> thing, in a CT-style system each key change should only require one check
> (by Bob) whereas with The Simple Thing each key change of Bob's requires
> all of his paranoid contacts to initiate a fingerprint check.
>
> The costs also seem more naturally aligned in CT-style systems: if Bob
> changes keys more often he's the one that has to do more checking of
> reports from monitors, whereas in The Simple Thing frequent changes by Bob
> impose a burden on others.
>

Another thing occurs to me, is this: what if Alice doesn't actually know
Bob? Then the out-of-band magic becomes even more magical.

What if Bob is, say, Twitter? That's a lot of out-of-band verification
Twitter's going to have to do!


>
> So CT probably has some usability advantages, at the cost of complexity
> and extra parties (auditors, monitors) needing to operate.
>
> A seemingly-obvious point I haven't seen yet: it's perfectly natural to
> have both systems in place. Nothing prevents layering The Simple Thing on
> top of a CT-style log. Paranoid Alice can certainly check out of band if
> she looks up a new key for Bob in the log and it's different from what
> she's used previously. Paranoid Bob can set up monitoring. Now you get
> detection if either sender or receiver is paranoid.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20141004/b0b4d78e/attachment.html>


More information about the Messaging mailing list