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.