Re: h2 ciphers

Amos Jeffries <> Fri, 16 October 2015 14:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4D7121B2D3F for <>; Fri, 16 Oct 2015 07:50:07 -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 LqAwoQwbS7bJ for <>; Fri, 16 Oct 2015 07:50:00 -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 F31D31B2D64 for <>; Fri, 16 Oct 2015 07:49:59 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1Zn6Hn-0005xI-KH for; Fri, 16 Oct 2015 14:47:11 +0000
Resent-Date: Fri, 16 Oct 2015 14:47:11 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Zn6Hk-0005vc-Bx for; Fri, 16 Oct 2015 14:47:08 +0000
Received: from ([] by with esmtp (Exim 4.80) (envelope-from <>) id 1Zn6Hg-0002kk-PC for; Fri, 16 Oct 2015 14:47:07 +0000
Received: from [] (unknown []) by (Postfix) with ESMTP id 3FBC1E6E9D; Sat, 17 Oct 2015 03:46:34 +1300 (NZDT)
To: Stefan Eissing <>
References: <> <> <>
From: Amos Jeffries <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Sat, 17 Oct 2015 03:45:57 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Hub-Spam-Report: AWL=-0.180, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1Zn6Hg-0002kk-PC f4a4612d8edc6f59b2d6e08d9547f925
Subject: Re: h2 ciphers
Archived-At: <>
X-Mailing-List: <> archive/latest/30374
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 17/10/2015 2:36 a.m., Stefan Eissing wrote:
>> 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.

For us on the server side too. HTTP/2 syntax and behaviour simply did
not exist a few years ago.

If you have a legacy client, fall back to 1.1  - *as 1.1*. Not as h2
with 0.9 / 1.x syntax and security hacks.

It is actually easier for us as servers to do this failover quietly
since we get told up front by the client whether it wants h2 or only
talks 1.x.

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

Good argument for not accepting h2 in the ALPN unless TLS/1.3 is being
negotiated. That was the ideal for the TLS situation anyway.

Illari already pointed out how to do the ordering so that h2 is
achievable within the TLS/1.2 restrictions.

The result is either h2 being used, or failover to 1.1. Any penalty paid
is on the less preferred protocol. Which just encourages its decline in
a polite and increasingly less painful way.