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 08:48:33 UTC