Re: Client Certificates - re-opening discussion

Mark Nottingham <mnot@mnot.net> Wed, 23 September 2015 00:14 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240781B3009 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Sep 2015 17:14:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02f_Zf7w6bPJ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Sep 2015 17:14:17 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ABA71B3006 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 22 Sep 2015 17:14:17 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ZeXdl-00060v-4r for ietf-http-wg-dist@listhub.w3.org; Wed, 23 Sep 2015 00:10:29 +0000
Resent-Date: Wed, 23 Sep 2015 00:10:29 +0000
Resent-Message-Id: <E1ZeXdl-00060v-4r@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1ZeXdd-00060A-Hq for ietf-http-wg@listhub.w3.org; Wed, 23 Sep 2015 00:10:21 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1ZeXdb-0007Wa-C5 for ietf-http-wg@w3.org; Wed, 23 Sep 2015 00:10:20 +0000
Received: from [192.168.0.21] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C5A5F22E260; Tue, 22 Sep 2015 20:09:54 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <F2A23F97-E114-40D3-8691-84CB7B54A791@greenbytes.de>
Date: Wed, 23 Sep 2015 10:09:51 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E549D977-DC88-4E39-B65B-EE674E541157@mnot.net>
References: <63DECDF0-AB59-4AFD-8E48-8C2526FD6047@mnot.net> <42DDF1C6-F516-4F71-BAE0-C801AD13AA01@co-operating.systems> <2F3BD1CB-042D-48AB-8046-BB8506B8E035@mnot.net> <CABcZeBNpjbNdeqxP_cwCDygk6_MVDoNhqcMEDmEvEBxztmonLg@mail.gmail.com> <20150918205734.GA23316@LK-Perkele-VII> <70D2F8CE-D1A2-440F-ADFC-24D0CE0EDCF1@greenbytes.de> <CABcZeBPNxEA6O324tnF3dbUCLD-a7uUvWYYjO1pnYwAm9cN2eA@mail.gmail.com> <CY1PR03MB1374F1CA73EFDA80C7CE44E887580@CY1PR03MB1374.namprd03.prod.outlook.com> <9BD53F44-94BA-4931-891A-BD94B5F440D0@gmail.com> <CY1PR03MB1374BE698FEB732EBB9BD96087460@CY1PR03MB1374.namprd03.prod.outlook.com> <68879535-44AB-4E68-BA42-827BA334D9A8@gmail.com> <CAJU8_nX3kOxTavtz6s8EV_M0wfvgQorDsVDRszqqebVEHh++kw@mail.gmail.com> <C6DB2FC1-AA9B-43B9-BF28-AFB6B2957F9E@gmail.com> <6B89D91E-8E76-46E0-A2B5-1E764DDC5AD0@greenbytes.de> <CAJU8_nX5jY6X0Nnd5Vke0wpYS3UCsmyzqvD6xoQ4u_L7Wfr3SQ@mail.gmail.com> <4456BAAA-125B-4038-AAC7-77A20F0C75B1@co-operating.systems> <CAJU8_nV4=iPowBOysL9Wz5Wyrm4Oi Ks0J4s6E 3fmCQmv9=MyHw@mail.gmail.com> <C874EAAC-FF26-42C6-BB6C-5785A6508664@bblfish.net> <CY1PR03MB137427E0C66A2297C844DDBF87460@CY1PR03MB1374.namprd03.prod.outlook.com> <F2A23F97-E114-40D3-8691-84CB7B54A791@greenbytes.de>
To: Stefan Eissing <stefan.eissing@greenbytes.de>
X-Mailer: Apple Mail (2.2104)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-8.2
X-W3C-Hub-Spam-Report: AWL=1.365, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1ZeXdb-0007Wa-C5 66f88e228b7bb432b48fa1510c9a0c9a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Client Certificates - re-opening discussion
Archived-At: <http://www.w3.org/mid/E549D977-DC88-4E39-B65B-EE674E541157@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30259
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Stefan,

> On 22 Sep 2015, at 7:08 pm, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
> 
> 
>> Am 21.09.2015 um 20:23 schrieb Mike Bishop <Michael.Bishop@microsoft.com>:
>> 
>> 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:
  http://httpwg.github.io/specs/rfc7540.html#rfc.section.9.2.1
  http://httpwg.github.io/specs/rfc7540.html#HTTP_1_1_REQUIRED

"""
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   https://www.mnot.net/