Hi all,
Simone/Xuelei/I wrote:
Per my understanding, application protocol should be negotiated before
>>>cipher suite and protocol version negotiated.
>>
>>This is not possible for HTTP/2.
>>Application protocol negotiation MUST happen*after* the TLS protocol
>>and the TLS cipher are negotiated.
>
>Yes, that's my understanding as well.
What are the behaviors of other vendors? Can we ask for a clarification
from both HTTP/2 and TLS WG?
and then Simone wrote:
I support Xuelei in that you should ask confirmation to the HTTP/2
editor.
Thanks for the encouragement, Simone. As you've probably heard, I did
contact the IETF HTTP/2 working group and posed several questions about
expected usage[1]. I'm combining those responses plus several other
points that came up since the last discussion. This may be repeating
some things already said, but serves as useful background info for those
here that might not be following closely:
1. HTTP/2 (aka H2) and TLSv1.3 were developed in parallel. The H2
designers wanted the ciphersuite restrictions in the proposed TLSv1.3.
But since TLSv1.3 wasn't ready, they compromised by allowing TLSv1.2 to
be used but with the restriction that only those ciphersuites that were
expected/allowed for TLSv1.3 could be used. That is, there is a
blacklist of ciphersuites for TLSv1.2: if a suite is present, it can't
be used in TLSv1.2. (e.g. no RSA KeyExchange, no CBC-based block
ciphers, no stream ciphers, etc.)
2. RFC 7301 says in a couple places that it would be advantageous to
have the chosen ALPN value used by the certificate selection mechanism
(See sections 1 & 4). Without a radical rewrite of the current
selection mechanism (n-tuple), that means ALPN selection should be done
before the ciphersuite is selected. We could also check after, but I
have a different approach (see below).
3. From the H2 working group discussion, a server instance will very
likely support both H2 and legacy HTTP/1.1. This means for servers that
prefer H2, any iterative cipher selection mechanisms needs to try the
H2-specific ciphersuites first, then legacy non-H2 suites. That is, the
suites must be ordered appropriately so that the ciphersuite selection
mechanism won't attempt a blacklisted suite before exhausting all
H2-acceptable suites. This ordering can be requested today in JSSE by
the server calling sslParameters.setUseCipherSuitesOrder(true). This
particular point won't matter when TLSv1.3 is in play, as we wouldn't
try those suites at all.
4. Clients may not know whether a server will be H2 or HTTP/1.1, so they
should also appropriately sort ciphersuites based on their ALPN
preferences. (H2 first, H1 second.)
5. For our SunJSSE, while I think our current enabled list order is
generally ok, we should probably reorder the ciphersuite priorities so
that the TLSv1.3 acceptable suites are up front, with the others
following. This prefers forward secrecy ciphersuites to our current
ordering. I am thinking we should probably do this for JDK 9, and maybe
backport as well. The current webrev (link below) doesn't have this yet.
6. To avoid downgrade attacks, applications should not provide for a
fallback mechanism. This includes ALPN selection.
Connection#1: {"h2", "http/1.1"} // Don't make two connections.
Connection#2: {"http/1.1"}
POODLE was a good example where allowing fallbacks bit hard.
Of course, we can't control this at the JSSE layer, it's the application
layer responsibility.
Tradeoff between A) change radically the OpenJDK implementation to
support an iterative processing of TLS protocols, extensions (all of
them), ciphers, aliases, etc. that would be future proof (if that is
even possible) and B) hack in just enough of what is needed to support
H2 today (for which we already have working examples) ?
Given where we are now schedule wise (integration currently due at the
end of September), and that SunJSSE is such an iterative implementation,
coming up with a multi-selector API is likely beyond what we can do at
this point.
(webrev link below).
IMHO, the following works well. I've added a new method that contains
the ordered list of ciphersuites still to be tried which is a hint for
ALPN selection, but we delay the actual ciphersuite selection until
after the ALPN value is chosen. So the algorithm is now:
0. Applications (especially server) might order suites with h2
first for TLSv1.2. sslParameters.setUseCipherSuitesOrder(true)
should be called on the server to ensure those suites are
tried first.
1. Start Handshake.
2. Internal server handshaker chooses the TLS version.
3. The internal server handshaker finds the client/server/protocol
version intersection of the suites, loads the initial ordered
list into a new method on a SSLSession (obtained by the
getHandshakeSSLSession()), then iterates through the
ordered list of ciph
