W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2015

Re: Fwd: Re: TLS ALPN Proposal v3

From: Bradford Wetmore <bradford.wetmore@oracle.com>
Date: Tue, 21 Jul 2015 17:52:25 -0700
To: ietf-http-wg@w3.org
Message-ID: <55AEE949.3060908@oracle.com>

We are working on our ALPN/H2 implementation for JDK 9, and want to 
clarify some assumptions about intended ALPN/H2 interactions/operations.

RFC 7301 (ALPN) suggests that the ALPN value be chosen so that 
certificate selection may take the chosen ALPN value into account:

     1. Introduction
     ...Further, it would be
     advantageous to allow certificate selection based on the negotiated
     application protocol.

and

     4. ...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.

If I'm reading the OpenSSL/NSS code right, they both do:

1. Protocol Selection
2. Extension Processing (including ALPN selection)
3. Ciphersuite selection

For SSL/TLS implementations such as OpenSSL/NSS that do iterative 
ciphersuite selection, that means that a blacklisted ciphersuite could 
be chosen for HTTP/2.  This is discussed in RFC 7540:

    Note that clients might advertise support of cipher suites that are
    on the black list in order to allow for connection to servers that do
    not support HTTP/2.  This allows servers to select HTTP/1.1 with a
    cipher suite that is on the HTTP/2 black list.  However, this can
    result in HTTP/2 being negotiated with a black-listed cipher suite if
    the application protocol and cipher suite are independently selected.

So a couple of questions:

1.  Are server sockets expected to support *BOTH* HTTP/2 and HTTP/1.1?

Depending on that answer:

2.  Are you expecting clients/server to try non-blacklisted ciphersuites 
first?  e.g. select H2 for ALPN, prioritize H2-appropriate suites first, 
select a suite and hope for the best?

I suppose we could do some pre-connect probing and disable any H2 suites 
that we know won't have appropriate key material.  If there are no 
H2-appropriate suites left, we can delete H2 from the server's ALPN 
list.  But that ciphersuite selection may fail for other reasons.

3.  If a ALPN of H2 is received along with a blacklisted suite, are 
clients expected to provide their own fallback by opening a second 
connection with H2 not in the ALPN list?

Connection#1:  {"h2", "http/1.1"}
Connection#2:  {"http/1.1"}

Thanks,

Brad
Received on Wednesday, 22 July 2015 00:53:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:46 UTC