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

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: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] 
Sent: Wednesday, January 27, 2016 12:48 AM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Martin Thomson <martin.thomson@gmail.com>; HTTP Working Group <ietf-http-wg@w3.org>
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

Received on Wednesday, 27 January 2016 23:01:47 UTC