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

Re: Fwd: Re: TLS ALPN Proposal v3

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 22 Jul 2015 00:54:39 -0700
Message-ID: <CABkgnnVBSZWRxwHE=yf+24emKGcoMcZ0Y52Qw7qM9kVpk3VUkQ@mail.gmail.com>
To: Bradford Wetmore <bradford.wetmore@oracle.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
This is a common set of conclusions to reach.  You certainly aren't
the first to conclude that this is not great.  If you consider all
pieces in isolation, you do get into a bind.

It's true that you can't completely disable all the bad cipher suites
if you ever hope to communicate with a legacy client.  That makes this
harder.

The right way to address this problem is to prioritize allowed cipher
suites over non-allowed cipher suites on both client and server.  You
have to prioritize on both ends because of variations in the way that
different servers implement cipher selection.

On 21 July 2015 at 17:52, Bradford Wetmore <bradford.wetmore@oracle.com> wrote:
> 1.  Are server sockets expected to support *BOTH* HTTP/2 and HTTP/1.1?

Absolutely.

> 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?

Are you talking about fallback logic?  That is, one connection attempt
without the blacklisted suites for h2 and then maybe a second with all
the suites you support and NOT h2.

That shouldn't be necessary if you are prioritizing correctly.  There
are alternatives (more below).

> 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?

I believe that Firefox will not do this.  It's a hard failure.

--

Speaking as an NSS developer, there is an established pattern there
that should work for this.

When processing the named_curve (soon named_group) extension for
elliptic curves, NSS will disable EC cipher suites if it does not find
a commonly supported curve.  This avoids the situation where you
select an EC cipher suite that you cannot use.

At the server, you could disable cipher suites that did not meet the
requirements based on the ALPN selection.  This is relatively
straightforward in NSS, though you have to provide a custom ALPN
callback, rather than relying on the NSS-provided callback.

That isn't of much use to a client, who is largely at the mercy of
servers (a curse that clients cannot avoid, I'm afraid).
Received on Wednesday, 22 July 2015 07:55:15 UTC

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