[messaging] Can a pre-shared public key prevent MITM-attacks?

[Justin King-Lacroix]

On 7 December 2015 at 15:12, Sam Lanning <sam at samlanning.com> wrote:

> > True, I missed out TOFU. I would argue, though, that TOFU gives you a
> weaker guarante: authentication *as long as the first message was not
> tampered with*.
>
> It's certainly a weaker guarantee, yes. But it gives a level of
> bootstrapping that can later be verified, which is better than no
> storage at all / exchanging keys each time for example.
>

It's a nice instance of trust-but-verify; that's definitely true.
Unfortunately, in the real world, the 'verify' step is usually omitted
(when was the last time you checked your SSH key fingerprints?).


>
> > TOFU systems also require careful design to achieve the properties you
> describe vis-a-vis MITM. In particular, while all encrypted messaging
> systems require a way to roll over the key, they must not support a "set
> session key to X" message, or similar, or the adversary can use it to
> switch from active mode to passive mode. This is not as trivial as it
> sounds -- I think SSL reauthentication lets you do exactly this.
>
> Very true, and interesting points. As an attacker you could then hide
> the fact that you have been attacking by switching keys, but it would
> sacrifice interception ability from that point onwards, and would
> require you to pick a reliable point in time to perform the switch.
> (i.e. you'd need to know the reliability and availability of your MITM
> attack)
>

You need to know the properties of your attack, yes. But you're not exactly
sacrificing anything: the key-switch is designed to allow you to enter
passive mode and still understand everything that's being said. Then, if
the your interception capability is intermittent, the session doesn't come
crashing down when you drop out (nor does your ability to resume
eavesdropping when it comes back).
Ideally, you'd then switch back to active mode whenever something
'interesting' (like rekeying) happens. Assuming you can see such
'interesting' transactions coming, and they don't occur during a dropout,
etc.

Hmm. I wonder if this means performing randomly-timed reauthentications is
a partial defence against this class of attack. (Or whether defending
against it is actually worthwhile.)



>
> > Otherwise, I agree with what you've said.
>
> =)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151207/6b880481/attachment.html>