Re: Client Certificates - re-opening discussion

Stefan Eissing <> Wed, 23 September 2015 08:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 565AA1A1AAE for <>; Wed, 23 Sep 2015 01:54:30 -0700 (PDT)
X-Quarantine-ID: <iXs4ug85hfhD>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BANNED, message contains text/plain,.exe
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iXs4ug85hfhD for <>; Wed, 23 Sep 2015 01:54:28 -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 144071A92E1 for <>; Wed, 23 Sep 2015 01:54:26 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZeflZ-0002gM-SY for; Wed, 23 Sep 2015 08:51:05 +0000
Resent-Date: Wed, 23 Sep 2015 08:51:05 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZeflT-0002dj-Vr for; Wed, 23 Sep 2015 08:51:00 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1ZeflR-00070Q-RK for; Wed, 23 Sep 2015 08:50:59 +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 D32E715A0053; Wed, 23 Sep 2015 10:50:34 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Stefan Eissing <>
In-Reply-To: <>
Date: Wed, 23 Sep 2015 10:50:35 +0200
Cc: HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <20150918205734.GA23316@LK-Perkele-VII> <> <> <> <> <> <> <> <> <> <> <> <CAJU8_nV4=iPowBOysL9Wz5Wyrm4Oi Ks0J4s6 E> <> <> <> <>
To: Mark Nottingham <>
X-Mailer: Apple Mail (2.2104)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: AWL=-1.168, BAYES_00=-1.9, RP_MATCHES_RCVD=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1ZeflR-00070Q-RK 730a53ec617a23b3da573d6a23795c40
Subject: Re: Client Certificates - re-opening discussion
Archived-At: <>
X-Mailing-List: <> archive/latest/30260
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Mark, thanks for pointing this out to me. 

On the one hand, sending a RST_STREAM with HTTP_1_1_REQUIRED seems at the right layer. On the other hand, the client gets no information where this restriction might apply. Or is it intended to be used in a GOAWAY and the client should only use HTTP/1 for this server? The description "Use HTTP/1.1 for the request" seems to pint to RST_STREAM.

One could advise a client that HTTP_1_1_REQUIRED indicates that the request uri ref indicates the server realm where this restriction applies. For Apache httpd at least, client cert renegotiation is a directory based configuration.

Further, a client thus falling back to HTTP/1.1 to trigger the proper TLS params, *could* try to "Upgrade:" to h2 again on the same request, given that all security requirements are fulfilled. This is outside the spec atm, right?

(I had already one site with "421 Ping Pong" reported, where the client got a 421, teared down the connection, opened a new one, got a 421 on a later request, teared down again, opened exactly as in the beginning a new one... all this does not match exactly this case, but it shows that there are interop issues lurking.)



> Am 23.09.2015 um 02:09 schrieb Mark Nottingham <>:
> Stefan,
>> On 22 Sep 2015, at 7:08 pm, Stefan Eissing <> wrote:
>>> Am 21.09.2015 um 20:23 schrieb Mike Bishop <>:
>>> I have no issue with defining something at the application layer that becomes a viable alternative to move toward.  In the meantime, though, we want a way for applications built on the old/current model to use HTTP/2.
>> Thanks, Mike. My feelings exactly.
>> We want sites to enable HTTP/2. We do not want them to crash and go down in flames, because the existing HTTP/1 config was not suitable. We'd like predictable (or at least defined) behaviour of clients when running into whatever the server sends back in such scenarios.
>> In order to completely avoid renegotiations on HTTP/2 (and I think we all agree on that), one approach would be to force the client back to HTTP/1.1 using another (new or open) connection. The response should indicate the realm where this restriction applies.
>> Note that servers may be unable to trigger client certs on connection setup. This often happens on the first request, triggering a renegotiation. Often specific TLS parameters only apply to special locations on a server (in existing configurations - I do not say that this is a good approach).
>> This may be done by extending the 421 response with additional headers to indicate the desired behaviour. It would be good to hear from people on the client side what their thoughts about this are.
> See:
> """
> This effectively prevents the use of renegotiation in response to a request for a specific protected resource. A future specification might provide a way to support this use case. Alternatively, a server might use an error (Section 5.4) of type HTTP_1_1_REQUIRED to request the client use a protocol that supports renegotiation.
> """
> Cheers,
> --
> Mark Nottingham

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782