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

[Yoav Nir <[e-mail]>]

> On 20 Oct 2015, at 9:10 PM, Martin Thomson <[e-mail]> wrote:
> 
> On 20 October 2015 at 05:31, Jason T. Greene <[e-mail]> wrote:
>> Wouldn't the semantics be a hell of a lot cleaner, and implementations a lot simpler, if we just pushed this to an HTTP cert auth protocol?
> 
> Yes, yes it would.  A better authentication mechanism might be better
> still.  But that would be a new protocol.  We have plenty of evidence
> to suggest that a new protocol would not be acceptable.  As I said, we
> are already at plan B.

An HTTP cert auth protocol is just an HTTP authentication method, much like Basic, Digest or the experimental ones we’re standardizing in http-auth. The framework is already there in all clients and servers.  It has the advantage that you don’t have to skip between protocol layers - it’s all in HTTP. This way the client is in control of which streams are authenticated and which are not, so Imari’s security hole could go away. 

Practically you probably don’t want to sign each request, so applications are likely to set a cookie (or tokbind) after a single authentication and use that to continue the authentication to other resources, but that’s the way they do it with other forms of authentication anyway.

Yoav