Re: [TLS] simplistic renego protection

[Eric Rescorla <[e-mail]>]

At Tue, 17 Nov 2009 08:25:37 -0800,
Michael D'Errico wrote:
> 
> 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.

Well, the other changes I've seen suggested pretty much amount to
discarding RI in favor of another approach, so I don't think
it's really surprising I didn't incorporate them into RI.


> 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).

I don't think this is entirely accurate.

It doesn't protect the combination of a lenient server and a client
which falls back to not using the extension at all, i.e., a client
which tolerates non-compliant servers which do not properly ignore
unknown extensions. Given that that's going to be a fairly small
fraction of servers and that those servers are pretty much by
definition unpatched (more or less the one case where you can
accurately detect vulnerability without a huge number of false positives)
I'm not seeing that it's a crisis to fail negotiation at this point.

With that said, the extra cipher suite solves this problem AFAICT
and I have no problem with adding that if it's WG consensus.


> (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.

Changing the version number in response to something other than a
version number advertisement seems extremely problematic to
me.


> (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).

Well, RI doesn't require changing the PRF or the virtual 

-Ekr