"Against Rekeying"

[Nicolas Williams]

On Thu, Mar 25, 2010 at 01:24:16PM +0000, Ben Laurie wrote:
> Note, however, that one of the reasons the TLS renegotiation attack was
> so bad in combination with HTTP was that reauthentication did not result
> in use of the new channel to re-send the command that had resulted in a
> need for reauthentication. This command could have come from the
> attacker, but the reauthentication would still be used to "authenticate" it.

It would have sufficed to bind the new and old channels.  In fact, that
is pretty much the actual solution.

> In other words, designing composable secure protocols is hard. And TLS
> isn't one. Or maybe it is, now that the channels before and after
> rekeying are bound together (which would seem to invalidate your
> argument above).

Channel binding is one tool that simplifies the design and analysis of
composable secure protocols.  Had channel binding been used to analyze
TLS re-negotiation earlier the bug would have been obvious earlier as
well.  Proof of that last statement is in the pudding: Martin Rex
independently found the bug when reasoning about channel binding to TLS
channels in the face of re-negotiation; once he started down that path
he found the vulnerability promptly.

(There are several champions of the channel binding technique who could
and should have noticed the TLS bug earlier.  I myself simply took the
security of TLS for granted; I should have been more skeptical.  I
suspect that what happened, ultimately, is that TLS re-negotiation was
an afterthought, barely mentioned in the TLS 1.2 RFC and barely used,
therefore many experts were simply not conscious enough of its existence
to care.  Martin was quite conscious of it while also analyzing a
tangential channel binding proposal.)

Nico
-- 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com