RFR: 8061798: Add support for TLS_FALLBACK_SCSV

[Florian Weimer]

On 01/29/2015 04:39 AM, Xuelei Fan wrote:
> Hi Florian,
> 
> Thanks for contribute this patch to OpenJDK.
> 
> The draft of TLS_FALLBACK_SCSV is moving pretty fast.  Would you mind
> wait for the integration until it becomes an official RFC in order to
> mitigate the potential compatibility impact?

The RFC is basically set in stone because code implementing it has
already been shipped.  I don't like the specification, and I don't like
how it happened.  But practically speaking, it's a done deal, even if
the IETF end up not publishing the RFC (which is extremely unlikely
because an RFC is the only way to get the SCSV code point reservation).

> I looked back the approach we used to support
> TLS_EMPTY_RENEGOTIATION_INFO_SCSV (RFC 5746).
> TLS_EMPTY_RENEGOTIATION_INFO_SCSV is treated as a cipher suite.
> Application can configure to enabled or disable this special cipher
> suite as normal:
>     SSLSocket.setEnabledCipherSuites(String[] suites)
>     SSSEngine.setEnabledCipherSuites(String[] suites)
> 
> What do you think if we use TLS_FALLBACK_SCSV as a cipher suite? If the
> enabled cipher suite list contains this cipher suites, client would send
> this cipher suite in ClientHello request.

We absolutely have to prevent that application developers set this SCSV
by accident.  Developers feel tempted to set TLS_FALLBACK_SCSV to
increase security, but this is very wrong.  Things will appear to work
just fine right now, but if the server side ever upgrades to TLS 1.3,
the handshake will fail to work (I called this a “time bomb” in the IETF
TLS WG discussion, because that's what it is).  Questions on the OpenSSL
mailing list (and misleading advice in response) show that this is a
real problem.

My hope is that with a new API, the risk that developers enable this
accidentally is reduced.  It makes it also more transparent to code reviews.

> If it is OK, may not need to define new public APIs any more.  As make
> it possible if this implementation is needed to backport to previous
> releases (In general, no APIs changes are allowed in JDK update releases).

I plan to backport only the server part, the client part is mostly there
for testing purposes.

-- 
Florian Weimer / Red Hat Product Security