You guys certainly were prolific in your discussions last night. ;)
Many comments to touch on, and I definitely won't have time today to
respond to everything.
Xuelei wrote:
> I don't think we really need to re-order the cipher suites.
Simone wrote:
> Of course you need to re-order in this case.
In an iterative implementation like SunJSSE is currently, if you want to
have the preference order of H2/H1, you need to try all of the
H2-compatible ciphersuites first. Once you try a non-H2-compatible
suite, the H2 matcher will fail, and it will then go to the H1 matcher,
which will succeed. This particular situation was discussed in RFC 7540.
> It might be not customers expected behavior to re-order/sort their
> preference of cipher suites or preference.
Are we are clear that the intention was never for the JDK to internally
resort the ciphersuites, but rather to provide an external helper
function (H2BLACKLISTCOMPARATOR) with which applications can do their
own sorting and pass the results to setEnabledCiphersuite()? I think
maybe the confusion came from the 3 roles you describe later.
> If there are three roles, OpenJDK, application, customers, there are
> three result:
For JDK developers, the line between application/customer is quite
blurry. You/I are concerned about the interface between the OpenJDK and
(application+customers). The application folks will mainly be handling
the customer configuration.
> {TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384}
BTW, in case anyone was wondering, both of these suites are on the RFC
7540 blacklist.
Simone wrote:
> for each cipher
> for each application protocol
> end
> end
>
> All the rest being equal, ciphers dominate application protocol
> selection.
Correct. That's the current proposal. It's a chicken/egg problem. The
KeyManager is part of the ciphersuite selection mechanims, and should
have a proposed ALPN value value to use (ala RFC 7301), but the ALPN
mechanism needs to have a ciphersuite in mind for it's calculation.
I will think over David's proposal over the weekend. Much of the I/O
required is already there using the JDK 1.8 method
SSLSocketFactory.createSocket(Socket s, InputStream consumed, boolean
autoClose), which was added for this very purpose. There's nothing to
do for SSLEngine.
Just a bit of history, we did consider a ClientHello parser when working
on SNI. I don't remember the details as to why we didn't add it, but the
SSLCapabilities/SSLExplorer classes in the JSSE sample code came from
that attempt. I have a vague recollection that the API was getting too
complicated in the time we had.
More next week.
Have a good weekend, all.
Brad
