TLS ALPN Proposal v3

[Bradford Wetmore]

Ok, I'll check with the HTTP/2 group tomorrow.  It appears the proper 
list is:

     ietf-http-wg at w3.org

Is that correct?

Brad



On 7/9/2015 8:29 AM, Simone Bordet wrote:
> Hi,
>
> On Thu, Jul 9, 2015 at 1:42 AM, Bradford Wetmore
> <bradford.wetmore at oracle.com> wrote:
>> SSLParameters is a configuration class which is used to configure
>> SSLSockets/SSLEngines.  SSLSession/ExtendedSSLSession is a class which holds
>> negotiated Session values.  getReceivedApplicationProtocols() represents the
>> Application Protocol values received from the peer, thus belongs in the
>> SSLSession.
>
> I suggest to rename
>
> ExtendedSSLSession.getRequestedApplicationProtocols()
>
> to
>
> ExtendedSSLSession.getPeerApplicationProtocols()
>
> The protocols are not really "requested", they are more "offered", but
> IIUC the reason to add "Requested" to this method is to distinguish it
> from SSLParameters.getApplicationProtocols() which returns the local
> protocols, and in that spirit I think "Peer" is better for
> ExtendedSSLSession.
>
>> Xuelei/Simone 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.
>
> Well, to be precise, either the application protocol is negotiated
> after the cipher (and you need cipher sorting to influence the cipher
> selection towards the application protocol you would like to choose),
> or it must happen at the same time - that is, cipher and application
> protocol must be chosen at the same time - but this implies that the
> action of choosing that tuple may be invoked multiple times with the
> current OpenJDK implementation.
>
> Note that I don't know if the fact that cipher selection is an
> iterative process is an OpenJDK implementation detail.
> If other implementations are not iterative, then perhaps they have a
> single moment where the tuple is chosen.
>
> I support Xuelei in that you should ask confirmation to the HTTP/2 editor.
> Also, remember that Firefox, Chrome, OpenSSL, nghttp2, etc. are all
> open source and their code is available to verify the behavior.
>
>> IIUC, the HTTP/2 blacklist is just strongly recommended ("...SHOULD NOT use
>> any of the cipher suites...black list"), but not required.  Such potential
>> peers must also support such a configuration, but in general, it will not.
>> See section 9.2.2.  I think it's still considered compliant to the spec tho.
>
>  From experience, if a server breaks this SHOULD NOT, it won't work
> with any browser.
> We had our share of pain trying to figure out interoperability with
> browsers for Jetty :)
> Sure, it's a SHOULD NOT, but it's like a MUST NOT if you want a
> browser to talk to a Java server (or a Java client to talk to a
> current HTTP/2 server).
>
>> Simone wrote two different ways to do selection:
>>
>>> 1) ... so that TLS protocol, cipher (possibly the alias too) and
>>> application protocol are chosen together, or
>>> 2) we separate the TLS protocol and
>>> cipher negotiation (and alias) in one step, and we perform application
>>> protocol selection afterwards.
>>
>> Rather than completely redo the JSSE selection mechanism with the
>> (version/ciphersuite/ALPN)-tuple idea (which would be a much more involved
>> API and behavior change), I think the more straightforward solution (2) is
>> better.
>
> That's what we do in Jetty's ALPN implementation too.
> Be aware that it rules out some possibility such as those mentioned by
> Michael from RFC 7301.
>
>>> Also, it is critical to detail how the mechanism work.
>>>
>>> Example implementations for SSLFunction would be great to have: the
>>> typical HTTP/2 case is to select the application protocol based on the
>>> TLS protocol and the already negotiated cipher.
>>
>> I have a "working" test example which shows how the ALPN APIs can be used
>> for HTTP/2 clients and servers. It is a minor configuration tweak to the
>> jdk/test/javax/net/ssl/templates/SSLEngineTemplate.java test that we use as
>> the basis for JSSE SSLEngine testing.
>
> Do you have a Java 9 server that can negotiate h2 with current browsers ?
>
>> http://cr.openjdk.java.net/~wetmore/8051498/webrev.04/test/javax/net/ssl/ALPN/SSLEngineAlpnHttp2.java.html
>>
>> See the configuration in createSSLEngines() around line 265 and 280.
>>
>>
>> http://cr.openjdk.java.net/~wetmore/8051498/webrev.04/test/javax/net/ssl/ALPN/Http2ApplicationSelector.java.html
>>
>> Note the HTTP/2 blacklist and reordering code.
>>
>> The code is not actually "working" yet (haven't merged API/impl repos yet),
>> but shows how to configure/use this API.
>
> Just a reminder that the cipher blacklist is only valid for TLS 1.2.
> For example, if the negotiated TLS protocol is 1.3, there is no need
> to look at the ciphers (nor to sort them).
>
> Thanks !
>