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 majord...@metzdowd.com