Re: [TLS] simplistic renego protection

[Michael D'Errico <[e-mail]>]

Stephen Farrell wrote:
> 
> Chris Newman wrote:
>> --On November 16, 2009 18:25:32 +0100 Martin Rex <[e-mail]> wrote:
>>> But when a proposal enters the IETF process, the IETF and the
>>> working group should discuss it based on its technical merits.
>> The IETF is about rough consensus and running code.  Technical merit is
>> one aspect of that.  Time to market can be important.  Technical
>> maturity of the specification can be important.  The best or perfect
>> proposal often takes longer to develop than the good enough proposal and
>> thus loses.  Just look at how badly HTTP is designed when it comes to
>> authentication -- but it was good enough to standardize.  The HTTP
>> Next-Generation working group failed because HTTP is good enough.
>>
>> draft-rescorla-tls-renegotiation-00 already has lots of running code;
>> and that's a traditional IETF litmus test that correctly makes
>> alternative proposals far less attractive.
> 
> Having watched the recent list traffic I find the above convincing.
> I'd love to see a -01 of the above containing the changes EKR has
> mentioned already, and then a WGLC on that.

I went back and re-read all his messages and the only change EKR
suggested was to use a magic cipher suite *only as a fallback* if
an initial attempt to use RI failed.  All other suggestions did not
convince him to make any changes.  I could be wrong, but that is
how the messages read.

Plus I've pointed out that RI does not protect the combination of a
lenient client and lenient server!  This is a severe drawback since
patched peers are still vulnerable during the transition period
where some servers remain lenient (allow current insecure
renegotiation).  The following fixes that since there is no fallback
needed and no reason for a client to not signal its support in every
handshake.

The whole point of RI is to get the previous handshake's verify_data
into the handshake messages of the current session.  This can be
done without extensions and does not require any fallback logic.

You just need three things:

   1) a client-to-server signal
   2) a server-to-client signal
   3) somehow incorporate the previous verify_data in the handshake

(1) can be achieved by simply incorporating a magic cipher suite in
the ClientHello.  Since that is the *only* change to the handshake,
it has zero possible interoperability problems.  Extensions are
known to be problematic; web browsers have extremely complicated
logic including reconnecting and falling back to not using extensions
to try to accommodate the various server implementations.  This magic
cipher suite signal would be used in all handshakes since it can not
cause any problems.  Existing browser fallback logic would not get
any more complicated.

(2) can be done many ways but I think Martin came up with a better
idea than the alert message I proposed.  It is to toggle the upper
bit of the low-order byte of the version in the ServerHello.  For
SSLv3, 0x0300 would become 0x0380; TLS 1.0, 0x0301 would become 0x0381,
etc.  This is forward-compatible too; the next version of TLS would
be 4.0, 0x0400.  This signal would be used in all handshakes from
SSLv3 through TLS 1.2.  The version in the record layer would NOT
change.

(3) can be done in a variety of ways.  RI sends the data over the
wire, but this is unnecessary since both the client and server know
it already.  EKR doesn't like the idea of a "virtual" handshake
message, but this is an easier way to incorporate the data than
requiring changes to three PRF computations (SSLv3, TLS 1.0/1.1, and
TLS 1.2).

I'm open to suggestions for a better (3) or even better (1) and (2),
though those seem sufficiently simple.

Mike