TLS ALPN Proposal v2

[Michael McMahon]

On 04/06/15 15:18, Simone Bordet wrote:
> Hi,
>
> On Thu, Jun 4, 2015 at 3:08 PM, Michael McMahon
> <michael.x.mcmahon at oracle.com> wrote:
>> 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.
> Currently, IIUC, the cipher selection is an iterative process where a
> cipher is attempted until one is negotiated.
> In this process, there is no looking at the application protocol.
>
> Here we're trying to find a solution for ALPN, and either we 1) look
> the application protocol in this iterative process (and therefore the
> SSLFunction is invoked multiple times), so that TLS protocol, cipher
> (possibly the alias too) and application protocol are chosen together,
> at once (for each iteration); or 2) we separate the TLS protocol and
> cipher negotiation (and alias) in one step, and we perform application
> protocol selection afterwards.
> The latter is how Jetty's ALPN works, and that's what I mean with *after*.
> For HTTP/2 it won't work to pick the application protocol before the
> cipher. Either at the same time, or after.
>
> That is why I asked to specify how the mechanism worked.

Okay. I've been looking at it from the client point of view, and
as far as I understand it, all of the information is available to the client
at the right time.

>> 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.
> If the server chooses a blacklisted cipher, and then "h2" as protocol,
> it's a non compliant server.
> Communication of clients with compliant (and properly configured)
> servers is guaranteed if the application protocol is chosen after (or
> at the same time of) the cipher.
>
> If I understand you correctly, you are proposing to rework the
> internal JDK code to perform TLS protocol, cipher, alias and
> application protocol in one point, which is then possibly iterated
> multiple times until a satisfactory tuple is selected ?
>
> I am fine with this approach too, but I guess the API will be very
> different from Jetty's ALPN and this current proposal (which is fine
> as well - does not have to be similar to Jetty's).
> I don't know enough about the TLS implementation to say how much work it is.
>
> Thanks !
>

Actually, I'm not proposing anything at this stage. But, I wonder if
it might be simpler to just make all relevant information available
to the existing negotiation API, rather than splitting it into separate 
calls

- Michael.