Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Subject: Re: H2 compatible ciphers
To: dev@httpd.apache.org
References: 
 <CAKQ1sVNx3g2PjkxG6z2LwqA6CuJeVv2L6SryVsMWp2SydoKFjQ@mail.gmail.com>
 <7785D0B9-E1C7-483E-B468-CBDFA99156BB@greenbytes.de>
From: Kaspar Brand <httpd-dev.2014@velox.ch>
Message-ID: <5622126A.7040601@velox.ch>
Date: Sat, 17 Oct 2015 11:18:34 +0200
MIME-Version: 1.0
In-Reply-To: <7785D0B9-E1C7-483E-B468-CBDFA99156BB@greenbytes.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 16.10.2015 12:45, Stefan Eissing wrote:
> If the blacklist in RFC 7540 proves to be totally bogus, I'd favor
> ditching it in our server checks.

Sharing Yann's surprise about this huge blacklist... I'm also wondering
if this won't become a Sisyphean task, in the end (will the httpwg
regularly amend that list, BTW, or how do they intend to prevent
"unwanted" cipher suites from being used with HTTP/2?).

Another - quite radical - approach would consist of using a whitelist,
which consists of a single cipher suite only: given that section 9.2 of
RFC 7540 states

"Implementations of HTTP/2 MUST use TLS version 1.2"

and section 9.2.2 further says

"deployments of HTTP/2 that use TLS 1.2 MUST support
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with the P-256
elliptic curve [FIPS186]"

then "H2Compliance on" would only have to make sure that this exact
suite is negotiated. (What this MTI cipher suite also means, IINM, is
that you can't run an RFC 7540 h2 compliant server with an ECDSA key
only, actually... not sure if that was really an intended effect of this
requirement.)

Kaspar