<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 7 December 2015 at 15:12, Sam Lanning <span dir="ltr"><<a href="mailto:sam@samlanning.com" target="_blank">sam@samlanning.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> 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*.<br>
<br>
</span>It's certainly a weaker guarantee, yes. But it gives a level of<br>
bootstrapping that can later be verified, which is better than no<br>
storage at all / exchanging keys each time for example.<br></blockquote><div><br></div><div>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?).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> 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.<br>
<br>
</span>Very true, and interesting points. As an attacker you could then hide<br>
the fact that you have been attacking by switching keys, but it would<br>
sacrifice interception ability from that point onwards, and would<br>
require you to pick a reliable point in time to perform the switch.<br>
(i.e. you'd need to know the reliability and availability of your MITM<br>
attack)<br></blockquote><div><br></div><div>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).</div><div>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.</div><div><br></div><div>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.)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Otherwise, I agree with what you've said.<br>
<br>
</span>=)<br>
</blockquote></div><br></div></div>