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

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.

Received on Friday, 25 September 2015 09:19:30 UTC