Resent-Date: Fri, 16 Oct 2015 13:24:13 +0000
Resent-Message-Id: <E1Zn4zV-00013X-2D@frink.w3.org>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <20151016130500.GB20506@LK-Perkele-V2.elisa-laajakaista.fi>
Date: Fri, 16 Oct 2015 15:23:44 +0200
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2051F7C9-9067-46E6-ACBD-8FC335F25B2A@greenbytes.de>
References: <78A44AE4-168D-4129-AF94-38FB66286711@greenbytes.de>
 <20151016130500.GB20506@LK-Perkele-V2.elisa-laajakaista.fi>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Received-SPF: pass client-ip=217.91.35.233;
 envelope-from=stefan.eissing@greenbytes.de; helo=mail.greenbytes.de
Subject: Re: alpn + ciphers
Archived-At: <http://www.w3.org/mid/2051F7C9-9067-46E6-ACBD-8FC335F25B2A@greenbytes.de>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

It seems you say: "There is a way to configure this.", which I totally =
believe you.

But I am not setting up new servers. I add HTTP/2 functionality to a =
server that is around for 20 years. That upgrade will arrive in existing =
configurations and my code, ideally, should act sanely in as many of =
them as it can.=20

This seems a problem in implementation the way things are right now, =
because the requirements of RFC 7540 cannot be verified at ALPN time. =
Which maybe is what it is.=20

I am just trying to find out if I overlooked something here.

//Stefan

> Am 16.10.2015 um 15:05 schrieb Ilari Liusvaara =
<ilariliusvaara@welho.com>:
>=20
> On Fri, Oct 16, 2015 at 01:28:27PM +0200, Stefan Eissing wrote:
>>=20
>> 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.
>>=20
>> 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.
>=20
> If you don't want to limit ciphers (but if you need to be PCI DSS
> compliant, you can limit it a lot, the only non-h2 ciphers you
> need is ECDHE-{RSA,ECDSA}-AES256-CBC (for Apple products).
>=20
> And you can also priorize the H2 ciphers over the rest, which
> should make the handshake go properly.
>=20
>=20
> -Ilari
>=20