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

[Mike Bishop <[e-mail]>]

Yes, the new thing would be "just" a new authentication mechanism, but the existing apps call down to the HTTP layer requesting the client cert, which asks TLS to either return or obtain the client cert.

As Martin has said, there's no opposition to a cert-based, or key-based, HTTP auth protocol being defined.  That's definitely something beneficial to the Internet that people could move toward in the future.  However, in the short term, we have applications which rely on the existing APIs and mechanisms -- the goal with this draft is simply as a compatibility measure.  Currently, those applications cannot use HTTP/2 over TLS 1.2 without one of the various hacks; in TLS 1.3, it will be less hacky.

You're arguing for a more idealized solution -- that's something I can get behind as a long-term direction, but we also have short-term issues that need a solution.  One does not preclude the other.

-----Original Message-----
From: Yoav Nir [mailto:[e-mail]] 
Sent: Monday, October 26, 2015 12:03 AM
To: Martin Thomson <[e-mail]>
Cc: Jason T. Greene <[e-mail]>; Ilari Liusvaara <[e-mail]>; HTTP Working Group <[e-mail]>
Subject: Re: Report on preliminary decision on TLS 1.3 and client auth


> 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