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