RFR: 8061798: Add support for TLS_FALLBACK_SCSV

[Xuelei Fan]

On 1/29/2015 5:59 PM, Florian Weimer wrote:
> 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).
> 
We may still have a few months to address this feature of JDK 9. I think
it might not be bad to wait for more progress of this RFC proposal, in
case the spec gets updates unexpectedly.

>> 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.
> 
It depends.  In other side, as would decrease the transparent for system
administrators.

>> 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.
> 
I would suggest to keep the JSSE APIs simple and small.  If an public
API is required to turn on/off TLS_FALLBACK_SCSV, using cipher suite is
an easy-to-use approach.

Thanks,
Xuelei