Re: Client Certificates - re-opening discussion

Yoav Nir <> Wed, 23 September 2015 20:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 719431B2BE3 for <>; Wed, 23 Sep 2015 13:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 efb-ic6O6QwZ for <>; Wed, 23 Sep 2015 13:39:23 -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 3B7591A009E for <>; Wed, 23 Sep 2015 13:39:22 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1Zeqlt-0002zM-N0 for; Wed, 23 Sep 2015 20:36:09 +0000
Resent-Date: Wed, 23 Sep 2015 20:36:09 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Zeqlm-0002yV-AB for; Wed, 23 Sep 2015 20:36:02 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Zeqlk-0006N2-L5 for; Wed, 23 Sep 2015 20:36:01 +0000
Received: by wiclk2 with SMTP id lk2so86406872wic.1 for <>; Wed, 23 Sep 2015 13:35:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7nVRfIwaeXXowqqJsdfOuQPL7coueqKW6F0X7FJYygc=; b=w5jcJva5HZh7f01LzWSZ42GruXUONNKKr417nhN0Xa334/3wjwLVvLyqX2Fy/isOn6 FO4bFBN0R92NL4jDexmHp3aXTBuwABGAxwT8V4XbcDABsqieWXxVyDECJDIBtIUps5X+ MrbUIfunsPzWbYJ75RctVFxbWIdcYlqGntWm8iihOul7MjOBFzpWG4avfSj2Wn075TI+ Z1V++vAqUIZ9v7fRa6loqohSCmVoJvIbeQVlcHejLee2yxeAnWwEs7VS94ezvX588wt0 PjZC/c5cCKD2zpnC0DQ0+6lVEZeWVESpEy/2hsToTmm6GNjCjMal01mQH4KD7RUD33hg Cv2w==
X-Received: by with SMTP id i3mr37702755wjz.75.1443040534221; Wed, 23 Sep 2015 13:35:34 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id f17sm8966449wjn.38.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Sep 2015 13:35:32 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_056C642D-F815-4BD2-A3B7-0BDCF0C07372"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Wed, 23 Sep 2015 23:35:28 +0300
Cc: Martin Thomson <>, Stefan Eissing <>, Mark Nottingham <>, HTTP Working Group <>
Message-Id: <>
References: <> <> <> <> <20150918205734.GA23316@LK-Perkele-VII> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Mike Bishop <>
X-Mailer: Apple Mail (2.2104)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.0
X-W3C-Hub-Spam-Report: AWL=-1.318, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1Zeqlk-0006N2-L5 41944e71210986bac28af0cf49abd601
Subject: Re: Client Certificates - re-opening discussion
Archived-At: <>
X-Mailing-List: <> archive/latest/30264
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I agree that it makes the most sense from the client’s perspective to close the HTTP/2 connection and move entirely to HTTP/1 once the H1R response is received.

It’s kind of sad, because most applications that I’ve seen have just one resource that triggers the renegotiation (ours is called “login_with_certs.html”), and everything else is authorized by the cookie that is set by the response to that request. The HTTP/2 connection could be safely used for everything else on the site.

But there is no way for the browser to know that. And trying each resource with the HTTP/2 connection and optionally moving it to the HTTP/1 connection sounds like a really poor idea.


> On Sep 23, 2015, at 6:58 PM, Mike Bishop <> wrote:
> I agree, it would have been nice to specify some level of scope on the HTTP_1_1_REQUIRED – but then again, the server code may not even know the scope of resources that trigger it, and fallback to HTTP/1.1 is always permissible.  If we receive H1R for one or more resources, we open a 1.1 connection and retry it/them.  If they succeed on 1.1, we’ll switch entirely to 1.1 for the remainder of that session.  (With some additional implementation-specific stuff around the client-cert case and not wanting to stall renegotiation waiting for UI.)
> From: Martin Thomson [] 
> Sent: Wednesday, September 23, 2015 8:26 AM
> To: Stefan Eissing <>
> Cc: Mark Nottingham <>; HTTP Working Group <>
> Subject: Re: Client Certificates - re-opening discussion
> On Sep 23, 2015 1:55 AM, "Stefan Eissing" < <>> wrote:
> > 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.
> The notion that you might infer something about other resources based on some unspecified dissection of a URL and a response seems to fragile to be wise. That suggests something explicit, which leads back to 421.
> > 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?
> Yeah, TLS implies ALPN.
> > (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.)
> Redirect loops happen too, so I imagine that this can be handled in a catchall.
> The ideal solution is to find ways to address all use cases in HTTP/2. For that, I agree that client authentication in response to a request will be needed.