Re: H2 compatible ciphers

[Kaspar Brand <ht...@velox.ch>]

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

Re: H2 compatible ciphers

[Stefan Eissing <st...@greenbytes.de>]

Yes, I think whatever improvements we make, they need to be open for admin overrides. OTOH the majority of the deployments will want to have sth like modern/intermediate/old and get whatever that exactly means delivered by us as regular updates in releases (or via their distros).

Especially with more sites adding https for h2 and hopefully let's encrypt coming online soon. 

> Am 17.10.2015 um 11:50 schrieb Reindl Harald <h....@thelounge.net>:
> 
> 
> 
>> Am 17.10.2015 um 11:18 schrieb Kaspar Brand:
>> 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.)
> 
> terrible idea because it would lead to disable new, safer and recommended ciphers in the future until somebody adds them to the whitelist
> 
> so users (clientside) would have to wait for openssl *and* apache after their browser has already support and with the current release cycles of all major browsers it's likely to end that way
> 

Re: H2 compatible ciphers

[Reindl Harald <h....@thelounge.net>]

Am 17.10.2015 um 11:18 schrieb Kaspar Brand:
> 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.)

terrible idea because it would lead to disable new, safer and 
recommended ciphers in the future until somebody adds them to the whitelist

so users (clientside) would have to wait for openssl *and* apache after 
their browser has already support and with the current release cycles of 
all major browsers it's likely to end that way