Re: Report on preliminary decision on TLS 1.3 and client auth

"Poul-Henning Kamp" <> Fri, 25 September 2015 09:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 307FB1A1EEA for <>; Fri, 25 Sep 2015 02:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.512
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bZGVx1rewNid for <>; Fri, 25 Sep 2015 02:25:36 -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 685601A219C for <>; Fri, 25 Sep 2015 02:25:32 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZfPAK-00065H-9g for; Fri, 25 Sep 2015 09:19:40 +0000
Resent-Date: Fri, 25 Sep 2015 09:19:40 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZfPAA-00064R-K2 for; Fri, 25 Sep 2015 09:19:30 +0000
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1ZfPA4-0000PU-LK for; Fri, 25 Sep 2015 09:19:29 +0000
Received: from (unknown []) by (Postfix) with ESMTP id 062F04F86F; Fri, 25 Sep 2015 09:18:58 +0000 (UTC)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id t8P9IMPE006819; Fri, 25 Sep 2015 09:18:32 GMT (envelope-from
To: Amos Jeffries <>
cc: Martin Thomson <>, HTTP Working Group <>
In-reply-to: <>
From: Poul-Henning Kamp <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Date: Fri, 25 Sep 2015 09:18:22 +0000
Message-ID: <>
Received-SPF: none client-ip=;;
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: 1ZfPA4-0000PU-LK b6b37191b79fa0e421a2b18898909b71
Subject: Re: Report on preliminary decision on TLS 1.3 and client auth
Archived-At: <>
X-Mailing-List: <> archive/latest/30272
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

In message <>, 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

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.