Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

[Brian Smith <[e-mail]>]

On Mon, Oct 20, 2014 at 11:56 AM, Manuel Pégourié-Gonnard <[e-mail]>
wrote:

> On 20/10/2014 19:32, Brian Smith wrote:
> > For compatibility reasons, clients should put the renegotiation info and
> > TLS_FALLBACK_SCSV at the end of the cipher suite list, to avoid this bug
> > and similar bugs in other server software. This should be added to the
> > draft too.
> >
> Currently, PolarSSL puts the renego SCSV at the beginning of the list and
> we
> didn't get any report of interop issues so far. However, if there's
> consensus
> that it's safer to put the SCSV at the end, I'll follow your advice and
> change that.
>
> (For the fallback scsv, obviously I added it at the end since we want to
> interop
> with the current version of OpenSSL.)
>

I am not sure if it is problematic to put the renegotiation_info SCSV
anywhere except the end. In NSS, it has always been at the end, as far as I
know. Not too long ago, NSS was changed to always use the TLS extension
instead of the SCSV except for SSL 3.0; see [1] for why. However, in
retrospect, this might have increased the amount of TLS extension
intolerance seen by NSS-based applications, if some servers are intolerant
to the renegotation_info extension but not other ones sent by NSS.

In the case of TLS_FALLBACK_SCSV, it was assigned the value { 0x56, 0x00 }.
>From past experience, we know that some implementations only look at the
second byte of the value. This means that some implementations may confuse
TLS_FALLBACK_SCSV with { 0x00, 0x00 }, which is TLS_NULL_WITH_NULL_NULL.  Thus,
if you put TLS_FALLBACK_SCSV ahead of any real cipher suites, some
implementations may attempt to negotiation TLS_NULL_WITH_NULL_NULL,
especially if that implementation is attempting to honor the client's
cipher suite preference order. If that were to happen, the best case
scenerio is that your client will refuse the server's choice of
TLS_NULL_WITH_NULL_NULL,
which is not good. By putting TLS_FALLBACK_SCSV at the end, you avoid this
problem with these broken servers, assuming you offer some cipher suite
that they actually support. See [2]. Note that these kind of broken servers
are the reason you'd be doing TLS intolerance fallback in the first place.

Cheers,
Brian

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=549042#c4
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=946147#c5