RE: Client Certificates - re-opening discussion

Mike Bishop <> Wed, 23 September 2015 16:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EA4D91A8754 for <>; Wed, 23 Sep 2015 09:02:34 -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 p-DU3uO_0eLD for <>; Wed, 23 Sep 2015 09:02:32 -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 3B27C1A8725 for <>; Wed, 23 Sep 2015 09:02:27 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZemSM-0003cU-Ou for; Wed, 23 Sep 2015 15:59:42 +0000
Resent-Date: Wed, 23 Sep 2015 15:59:42 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZemSE-0003bJ-1W for; Wed, 23 Sep 2015 15:59:34 +0000
Received: from ([] by with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1ZemS4-0007mn-Iw for; Wed, 23 Sep 2015 15:59:33 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6n3UKBo7zhcELiCTdRtH9xSndz9YdhWmkCzWqXJVoUQ=; b=PnsEb2ngqdiMwMuzs3jk0fkF6xWynApgQ8h3cbLQh708O4doOwB14ATXJBHczw+uQ9Cf3eDBwFAnjkV2NFGWY+gzi8vb7OT5c9y6WCKsWPmizKsbvftKcnilz6fPGPcD6MW/DGL7IeTfDuSXwuD8DLdVPCQDCLf1ob48XWq6QPw=
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 23 Sep 2015 15:58:56 +0000
Received: from ([]) by ([]) with mapi id 15.01.0274.009; Wed, 23 Sep 2015 15:58:56 +0000
From: Mike Bishop <>
To: Martin Thomson <>, Stefan Eissing <>
CC: Mark Nottingham <>, HTTP Working Group <>
Thread-Topic: Client Certificates - re-opening discussion
Date: Wed, 23 Sep 2015 15:58:56 +0000
Message-ID: <>
References: <> <> <> <> <20150918205734.GA23316@LK-Perkele-VII> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; CY1PR03MB1376; 5:J9VUONdC7KeYxIetvuYuRpl7nT2Ss89JodhCMBHzUAb7Iq8fPI5fSrTV2LvNEpuPBg8xnuPVSLpjjlKy6ylq38I/nIPohQJRMd1S6PE5m2ojxYkXpCDqhTli/o7SFZNYHYh1g0af5ybC3FEDeSKY/Q==; 24:b+AmFanbKoRKT4NXTCUecYHBGFQqYD7kVVG9TffYZ/SGmyMJjHvDb+p3tj+V9WtVZzeeibc2sAB75RKiEKvsxND71YhZtfIWkegK7CSPpcA=; 20:l7UNwt0+zF5vlBOQ6SMQQ/OVpT3vUx28KBDT5KMbeC+ufBK6Yp/BE49YPXvP/Wi+wAaUEAgLzAxf1I2NPD9VCA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB1376;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(61426024)(61427024); SRVR:CY1PR03MB1376; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB1376;
x-forefront-prvs: 07083FF734
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(377454003)(24454002)(19580395003)(93886004)(106116001)(5002640100001)(81156007)(68736005)(77096005)(64706001)(16236675004)(19580405001)(8990500004)(2950100001)(10400500002)(5001770100001)(102836002)(97736004)(5004730100002)(5003600100002)(15975445007)(5001860100001)(2900100001)(66066001)(5007970100001)(99286002)(10290500002)(87936001)(11100500001)(86612001)(46102003)(40100003)(77156002)(5001830100001)(5005710100001)(101416001)(92566002)(10090500001)(76576001)(33656002)(4001540100001)(62966003)(76176999)(86362001)(189998001)(122556002)(74316001)(54356999)(50986999)(19300405004)(105586002)(19625215002)(19609705001)(5001960100002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB1376;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR03MB13742717AB92BB68C127B57187440CY1PR03MB1374namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2015 15:58:56.6507 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB1376
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-1.5
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: 1ZemS4-0007mn-Iw 848263b8b22e760f427d33a54d957945
Subject: RE: Client Certificates - re-opening discussion
Archived-At: <>
X-Mailing-List: <> archive/latest/30262
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.