Re: h2 ciphers

Stefan Eissing <> Fri, 16 October 2015 13:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B8A131B2B34 for <>; Fri, 16 Oct 2015 06:39:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.312
X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QTGsbto1dxCK for <>; Fri, 16 Oct 2015 06:39:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B41E1B2B4D for <>; Fri, 16 Oct 2015 06:39:33 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1Zn5Bj-0002Uq-5N for; Fri, 16 Oct 2015 13:36:51 +0000
Resent-Date: Fri, 16 Oct 2015 13:36:51 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Zn5Be-0002U4-TA for; Fri, 16 Oct 2015 13:36:46 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1Zn5BZ-0004NB-Ra for; Fri, 16 Oct 2015 13:36:46 +0000
Received: from [] (unknown []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 9AFEC15A035F; Fri, 16 Oct 2015 15:36:17 +0200 (CEST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Stefan Eissing <>
In-Reply-To: <>
Date: Fri, 16 Oct 2015 15:36:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Amos Jeffries <>
X-Mailer: Apple Mail (2.3094)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: AWL=-2.205, BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1Zn5BZ-0004NB-Ra 675a1823b5a391a933c2de89624cb7fe
Subject: Re: h2 ciphers
Archived-At: <>
X-Mailing-List: <> archive/latest/30372
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> Am 16.10.2015 um 15:08 schrieb Amos Jeffries <>:
> On 16/10/2015 11:35 p.m., Stefan Eissing wrote:
>> In the documentation at the "modern" compatibility specification includes the following ciphers:
>> [...]

>> but RFC 7540 includes TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ECDHE-RSA-AES128-SHA) and all those others as a MAY for INADEQUATE_SECURITY.
>> Now, assuming I got the cipher names correct, what am I to check for? Shall I be liberal in what I accept - again?
> The RFC is the specification. If a browser does not follow it that is a
> bug in their implementation (or maybe just their documentation), do not
> make matters worse by adding a bug to your code.

I do not want to, but see my other mail about ALPN+cipher timing that seems to make this difficult.

> HTTP/2 was designed to be implemented from a clean-slate situation.

Insert "on the client side", please.

> Everybody is building new code based on the same spec, so there is no
> legacy behaviours to be tolerant about. Methods of extending the
> protocol are also explicitly defined and explicitly negotiated when used
> to make feature support (or lack of it) a defined state within the
> protocol itself.

The problem seems to be that during ALPN selection, the TLS connection is not in a defined state. I seem to be unable to verify all requirements before code gives an answer to the selected protocol. And that might have nothing to do with the specification but with the TLS APIs. And there certainly is no clean slate there.

If this cannot be solved in code, we can only address this in configuration documentation. Which sucks.