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

[David-Sarah Hopwood <[e-mail]>]

Michael D'Errico wrote:
> I think that it would be good to find a unified solution that
> everybody is happy with, and believe that this may be it:
> 
> 
>   1) Client-to-Server signalling can be done in either of
>      two ways:
> 
>      A) an empty Secure_Renegotiation (SR) extension, or
>      B) a "magic" cipher suite
> 
>   2) Server-to-Client signal is always an empty SR extension
> 
>   3) Incorporate previous verify_data into Finished calc.
> 
> 
> The particulars:
> 
> A client that currently sends any other extensions MUST also
> send the empty SR extension.
> 
> A client that currently does not send any extensions MAY send
> the empty SR extension, or MAY send the magic cipher suite.
> 
> In response to either 1A or 1B, the server responds with an
> empty SR extension.  The only ugliness is this apparently-
> unsolicited extension returned by the server in response to
> the magic cipher suite.  I used to be against this, but have
> since decided that it is no more ugly than flipping a version
> bit or any of the other ideas.

I fully support this approach. The extension is not really
"unsolicited" in this case.

> It remains to be decided if adding the verify_data to the
> handshake message stream is the right way to do (3), or if
> changing the PRF in some way is better, such as changing the
> seed to be the handshake message hash appended with the old
> verify_data, or some other method.

I previously argued for changing the use of the PRF in the Finished
computation, mainly in order to ensure that the possible PRF inputs
for modified and unmodified Finished computations would be disjoint.
However, that would have the disadvantage (pointed out by Bodo Möller)
that the data signed in any CertificateVerify message wouldn't include
the old verify_data, unless that were also explicitly changed.

The old verify_data should not just be appended to the handshake_messages
without any further encoding, though, because it might match the bytes
of some valid handshake message. In that case, there is the possibility
that a MITM might insert the old verify_data into the stream sent to
one peer, as though it were a handshake message. If that peer is using
the unmodified Finished computation (either because it is unpatched or
it is doing an initial handshake), then it may end up computing the same
Finished hash as the other peer that is using the modified computation.

I haven't gone through the details of this attack thoroughly enough
to be sure it will work, but it is too near working for comfort.

So, we could either:

1. Change the use of the PRF and also change CertificateVerify (if
   used):

    verify_data =
      PRF(master_secret, finished_label, Hash(handshake_messages)
                                         + previous_verify_data)
        [0..verify_data_length-1];

    struct {
        digitally-signed struct {
            opaque handshake_messages[handshake_messages_length];
            switch (is_renegotiation) {
              case false:
                  struct {};
              case true:
                  opaque previous_verify_data[previous_verify_data_length];
            };
        }
    } CertificateVerify;

2. Add the old verify_data to handshake_messages preceded by the encoding
   of a fatal alert. Then, attacks of the kind described above can't work
   because the unpatched peer would first process the alert and abort the
   handshake.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com