Re: [TLS] Quest for Unified Solution to TLS Renegotiation

[Martin Rex <[e-mail]>]

Eric Rescorla wrote:
> 
> At Wed, 25 Nov 2009 15:19:51 -0800,
> Michael D'Errico wrote:
> > The complaint I have about sending the verify_data over the wire is
> > that that alone does not plug the hole.  You need to take the extra
> > step to check that it's correct, and a maintenance programmer not
> > intimately familiar with TLS might miss this fact.
> 
> I don't find this argument very compelling. There are all sorts of
> ways to screw up your TLS implementation that are worse than this
> and are difficult/impossible to detect from the other side. E.g.,
> 
> - Weak randomness
> - Failure to check buffers leading to buffer overflows
> - Failure to check certs
> 
> TLS relies throughout on the assumption that the other side is
> implemented more or less correctly. If we can't count on that,
> we have bigger problems than this issue.

If I look at the TLS renegotiation vulnerability,
then I think the SSLv3 designers who put renegotiation
in screwed it up in two ways:

  -  they didn't authenticate the enclosing TLS session
     in the renegotiation handshake.

  -  they used the exact same algorithm to authenticate
     initial authentications and renegotiations,
     and the result is that initial handshake can be
     proxied into renegotiations.

I think that we should not repeat either of these mistakes.


-Martin