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

Re: alpn + ciphers

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 16 Oct 2015 12:31:18 -0700
Message-ID: <CABkgnnVz=OyHNvpoEjSBAiLas_fqmHwL_FkvdFtemT9r6=BEyg@mail.gmail.com>
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
The solution that NSS supports is similar to what we do for other
extensions that affect cipher suite selection.

For ECC the named_curves extension lists some curves.  If you don't
support any of the listed curves, you can't select an ECC-based cipher
suite (either ECDHE or ECDSA).  Thus, in the extension handler, the
stack checks for a good curve, and if it doesn't find one, it disables
all of the affected cipher suites.

Here, the callback can select a protocol as normal.  If it is h2, then
it can disable all the blacklisted ciphers.

On 16 October 2015 at 04:28, Stefan Eissing
<stefan.eissing@greenbytes.de> wrote:
> A question regarding interworking and ALPN + ciphers:
>
> During ALPN callbacks by popular SSL libs such as openssl, the cipher has/may not have been selected. This is a potential interworking problem when h2 is proposed, only to have the connection shutdown with INADEQUATE_SECURITY afterwards.
>
> I am not certain if this is depending on the order TLS extensions appear in the client hello or the particular openssl implementation. Potentially, I could try to change the cipher list during the ALPN callback, but if that will influence things, is probably also not well defined. This you get, when you mix layers, I assume.
>
> I am not sure what is the best way to address this. Limiting the cipher list to only highest grade is often not an option for a server. Any advice appreciated.
>
> //Stefan
Received on Friday, 16 October 2015 19:31:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC