W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

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

From: Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Wed, 27 Jan 2016 10:47:59 +0200
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20160127084759.GA8247@LK-Perkele-V2.elisa-laajakaista.fi>
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

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

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.

Received on Wednesday, 27 January 2016 08:48:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC