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
