RE: FW: New Version Notification for draft-thomson-http2-client-certs-01.txt

[Mike Bishop <[e-mail]>]

Require EMS:  https://github.com/MikeBishop/http2-client-certs/commit/dfa59df62aec64044a407b0e8f67704e8eb91981
Smaller export:  https://github.com/MikeBishop/http2-client-certs/commit/3880e6069480523fcdfa6130fd28bc26ff6ebe9f
Cautions on AUTOMATIC_USE:  https://github.com/MikeBishop/http2-client-certs/commit/f1479486149e3d815662358d60d7be0bd877952c

I'm not doing the signature/hash changes quite yet, because I'm not sure what we want to restrict.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Wednesday, January 27, 2016 12:48 AM
To: Mike Bishop <[e-mail]>
Cc: Martin Thomson <[e-mail]>; HTTP Working Group <[e-mail]>
Subject: Re: FW: New Version Notification for draft-thomson-http2-client-certs-01.txt

On Wed, Jan 27, 2016 at 12:00:36AM +0000, Mike Bishop wrote:
> I believe the other comment is also around AUTOMATIC_USE, since both 
> occurrences of "future streams" are in that context.  Basically, it 
> means any future stream on which the server would have made the same 
> request, the server can just use the provided cert and not burn an RTT 
> asking.

And requests where that cert is inapporiate MUST NOT made on that connection.

Also, can it apply to streams that are none of:
1) The stream AUTOMATIC_USE is sent on
2) Stream in IDLE.
3) Stream in PUSH_PROMISE

At the time AUTOMATIC_USE is sent?

If yes, that would be a nasty surprise...

> Yes, the client loses visibility into whether the cert has been used, 
> and loses the ability to *not* use the cert if it chooses.  That's a 
> trade-off the client can make -- if it wants to retain those 
> capabilities (at the expense of 1 RTT per request), it just doesn't 
> set AUTOMATIC_USE.

I don't think server chosing to ignore cert is a problem, as it is equivalent to cert just provoding no privilege at all. But using a cert that should not be used is a *serious* security problem in presence of more than 2 parties (like in Web (but Web is far from being the only place where security problems happen)).

> The client makes the call -- and as Martin points out, it's 
> state-changing for the connection.  Once you AUTOMATIC_USE a 
> certificate, the server MAY apply it to any future request you make on the connection.
> If you change your mind later, new connection (and presumably GOAWAY 
> the old one).

Actually, in many cases where one would want to revoke certificate use, the old connection is not GOAWAY'd as it still might be useful.

> As to requiring EMS,

Basically, if you don't require EMS, maliscous server can hijack autenticated connection and misuse the certificates. HTTP/2 TLS use guidelines don't even come close to being able to prevent attacks like this.

> reducing exporter, and appropriate HashAndSignature algorithms, I'll 
> defer to those with more expertise in TLS-land.

Basically, I favor dropping insecure or excessively weak algorithms from new specifications or versions, even at severe cost to deploy- ability. We have gotten burned *far* too many times from not doing that, and *will* get burned in future if we continue allowing those.



-Ilari