TLS ALPN Proposal v2

[Xuelei Fan]

On 6/4/2015 8:19 PM, 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.
> 
Why? Is it a spec of HTTP/2?  It is a point I don't understand now.
Please help with more details.

>> 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,
Here is an example to explain the "rerouting".

For example, there a four entities, an TLS client, a router, an http/2
over TLS server, and an http/1.1 over TLS server.
1. the client request a connection to the http/2 server, the TCP
connection is established between the client the router at first.
2. the router analysis the ClientHello message, and reroute the
connection to the http/2 server.
3. the client and http/2 server negotiate the TLS connection, including
the SSL protocol and cipher suite.

The router should not be able to play man-in-the-middle negotiation if
it does not know the server credentials.

> 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.
>
See my question above.


> 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.
> 
See my question above.

Thanks,
Xuelei