Re: Report on preliminary decision on TLS 1.3 and client auth
"Poul-Henning Kamp" <phk@phk.freebsd.dk> Fri, 25 September 2015 09:25 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 307FB1A1EEA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 25 Sep 2015 02:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.512
X-Spam-Level:
X-Spam-Status: No, score=-5.512 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 bZGVx1rewNid for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 25 Sep 2015 02:25:36 -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 685601A219C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 25 Sep 2015 02:25:32 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ZfPAK-00065H-9g for ietf-http-wg-dist@listhub.w3.org; Fri, 25 Sep 2015 09:19:40 +0000
Resent-Date: Fri, 25 Sep 2015 09:19:40 +0000
Resent-Message-Id: <E1ZfPAK-00065H-9g@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 <phk@phk.freebsd.dk>) id 1ZfPAA-00064R-K2 for ietf-http-wg@listhub.w3.org; Fri, 25 Sep 2015 09:19:30 +0000
Received: from phk.freebsd.dk ([130.225.244.222]) by maggie.w3.org with esmtp (Exim 4.80) (envelope-from <phk@phk.freebsd.dk>) id 1ZfPA4-0000PU-LK for ietf-http-wg@w3.org; Fri, 25 Sep 2015 09:19:29 +0000
Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 062F04F86F; Fri, 25 Sep 2015 09:18:58 +0000 (UTC)
Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id t8P9IMPE006819; Fri, 25 Sep 2015 09:18:32 GMT (envelope-from phk@phk.freebsd.dk)
To: Amos Jeffries <squid3@treenet.co.nz>
cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
In-reply-to: <5603745A.7020509@treenet.co.nz>
From: Poul-Henning Kamp <phk@phk.freebsd.dk>
References: <CABkgnnWREq6X+chcvookChGAZGxkJ6Zs_7FGwz7Mbn12XMxewQ@mail.gmail.com> <5603599F.8090303@treenet.co.nz> <CABkgnnVq9FDeGf_=JF0m0AkgfO1G3DVV2QN_aPrbYnFtfRLFrw@mail.gmail.com> <5603745A.7020509@treenet.co.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6817.1443172698.1@critter.freebsd.dk>
Date: Fri, 25 Sep 2015 09:18:22 +0000
Message-ID: <6818.1443172702@critter.freebsd.dk>
Received-SPF: none client-ip=130.225.244.222; envelope-from=phk@phk.freebsd.dk; helo=phk.freebsd.dk
X-W3C-Hub-Spam-Status: No, score=-5.3
X-W3C-Hub-Spam-Report: AWL=-1.447, BAYES_00=-1.9, RP_MATCHES_RCVD=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1ZfPA4-0000PU-LK b6b37191b79fa0e421a2b18898909b71
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Report on preliminary decision on TLS 1.3 and client auth
Archived-At: <http://www.w3.org/mid/6818.1443172702@critter.freebsd.dk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30272
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>
-------- In message <5603745A.7020509@treenet.co.nz>, Amos Jeffries writes: >Ah. Sorry I seem to have misunderstood yoru meaning of "provides the >proof that a server needs to regard the entire session to be authentic" >to mean the cert was connection-wide. I would like to remind people that, contrary to widespread assumptions, HTTP doesn't have "sessions". Sessions are typically implemented by mistaking (groups of) connections for a session, or by means of opaque unstandardized cookies. A client cert most naturally applies to the session between the client and the server, no matter which connections and requests that session might consist of. But there is no way at the standardized protocol level to tell which connections and requests belong to any particular sessions. The only two architecturally clean solutions I can see are: A) Add the concept of sessions to HTTP, so we can tie the client cert to one of them. B) Point people to the End-to-End Argument, and make the client sign each subsequent request with its cert. A is at best a long term goal. Probably worth persuing for this and many other reasons, but unlikely to happen until HTTP/3. B is interesting in that it is relatively straightforward, can be applied to all versions of HTTP (if done right) and lays down ground-work which can later be extended to offer integrity (in both directions) without the excess baggage of secrecy. There are some issue with B, in particularly the part about what headers gets signed and what to do if proxies munge them along the way. I'd probably just let the signature enumerate which headers it signs, and make it a policy issue which headers it is a good idea to sign. In real life, the server would return a indication to the client along the lines of "I'd like you to sign your headers, using a cert matching this expression", and if it does, fine, if not the server will have to check policy for what to do. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
- Report on preliminary decision on TLS 1.3 and cli… Martin Thomson
- Re: Report on preliminary decision on TLS 1.3 and… Amos Jeffries
- Re: Report on preliminary decision on TLS 1.3 and… Martin Thomson
- Re: Report on preliminary decision on TLS 1.3 and… Amos Jeffries
- Re: Report on preliminary decision on TLS 1.3 and… Martin Thomson
- Re: Report on preliminary decision on TLS 1.3 and… Ilari Liusvaara
- Re: Report on preliminary decision on TLS 1.3 and… Poul-Henning Kamp
- Re: Report on preliminary decision on TLS 1.3 and… Yoav Nir
- Re: Report on preliminary decision on TLS 1.3 and… Poul-Henning Kamp
- Re: Report on preliminary decision on TLS 1.3 and… Martin Thomson
- Re: Report on preliminary decision on TLS 1.3 and… Poul-Henning Kamp
- Re: Report on preliminary decision on TLS 1.3 and… Kyle Rose
- Re: Report on preliminary decision on TLS 1.3 and… Martin Thomson
- Re: Report on preliminary decision on TLS 1.3 and… Willy Tarreau
- Re: Report on preliminary decision on TLS 1.3 and… Poul-Henning Kamp
- Re: Report on preliminary decision on TLS 1.3 and… Ilari Liusvaara
- Re: Report on preliminary decision on TLS 1.3 and… Willy Tarreau
- Re: Report on preliminary decision on TLS 1.3 and… Willy Tarreau
- Difffent ways to authenticate (Was: Re: Report on… Ilari Liusvaara
- Re: Report on preliminary decision on TLS 1.3 and… Martin Thomson
- Re: Report on preliminary decision on TLS 1.3 and… Ilari Liusvaara
- Re: Report on preliminary decision on TLS 1.3 and… Jason T. Greene
- Re: Report on preliminary decision on TLS 1.3 and… Martin Thomson
- Re: Report on preliminary decision on TLS 1.3 and… Martin Thomson
- Re: Report on preliminary decision on TLS 1.3 and… Kyle Rose
- Re: Report on preliminary decision on TLS 1.3 and… Martin Thomson
- Re: Report on preliminary decision on TLS 1.3 and… Kyle Rose
- Re: Report on preliminary decision on TLS 1.3 and… Yoav Nir
- RE: Report on preliminary decision on TLS 1.3 and… Mike Bishop
- Re: Report on preliminary decision on TLS 1.3 and… Yoav Nir