TLS ALPN Proposal v2

[Michael McMahon]

On 04/06/15 13:19, Simone Bordet wrote:
> Hi,
>
> On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>> Per section 4, RFC 7301:
>>    "... The
>>     "application_layer_protocol_negotiation" ServerHello extension is
>>     intended to be definitive for the connection (until the connection is
>>     renegotiated) and is sent in plaintext to permit network elements to
>>     provide differentiated service for the connection when the TCP or UDP
>>     port number is not definitive for the application-layer protocol to
>>     be used in the connection.  By placing ownership of protocol
>>     selection on the server, ALPN facilitates scenarios in which
>>     certificate selection or connection rerouting may be based on the
>>     negotiated protocol."
>>
>> 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.

What do you mean by "after"? As far as TLS is concerned, all of this
negotiation happens in one negotiation. The client proposes a list of
ciphers and application protocols. The server chooses a cipher
and application protocol and sends back its choices.

The HTTP/2 RFC specifically warns against splitting this negotiation
with the example that a client could propose a mandatory TLS 1.2 cipher,
but which is black-listed by HTTP/2. If (internally) the server chooses 
that cipher first,
without knowing the application protocol is going to be HTTP/2
then you end up with a non-compliant connection that will probably have
to be closed for reason of insufficient security.

- Michael

>> And the connection may be
>> rerouted (even to different machines) for further operation.  The
>> requested application protocols list should be the only information for
>> the selection of a suitable application protocol.
> Not sure what you exactly mean here, but you can't pick the HTTP/2
> protocol unless you have the TLS protocol and TLS cipher available.
> So *only* the list of protocol sent by the client is not enough for
> HTTP/2, we would need additional contextual information.
>
> What a HTTP/2 aware load balancer written in Java that offloads TLS
> would need to do is to negotiate the TLS protocol, negotiate the TLS
> cipher, *then* negotiate the application protocol (whether "h2" or
> "http/1.1"), and with the last information pick a backend server,
> typically forwarding clear text bytes to the backend.
>
> Thanks !
>