TLS ALPN Proposal v5

[Bradford Wetmore]

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