W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: Report on preliminary decision on TLS 1.3 and client auth

From: Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Tue, 20 Oct 2015 09:24:56 +0300
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20151020062455.GA476@LK-Perkele-V2.elisa-laajakaista.fi>
On Mon, Oct 19, 2015 at 03:10:17PM -0700, Martin Thomson wrote:
> On 23 September 2015 at 10:16, Martin Thomson <martin.thomson@gmail.com> wrote:
> > Here is a summary of the applicable pieces, plus what I options it provides
> > HTTP/2...
> 
> With the help of Mike Bishop [7], I've just submitted a draft that
> describes option 2 in more detail, including something for TLS 1.2.
> 
>   https://tools.ietf.org/html/draft-thomson-http2-client-certs-00

How does client refuse to change authentication on existing connection
and open a new one for new authentication[1]?

Because client can be rather easily forced into situation where the
existing connection can't change authentication without resetting
potentially numerious streams first (e.g. streams from cross-origin
XMLHttpRequest/Fetch non-credentials[2][3]).

Or is the browser supposed to reset all offending streams before
changing authentication?


[1] AFAIK, Chrome does it like that even with HTTP/1.1.

[2] Change authentication with such stream open and you have an
security hole.

[3] And there are more cases relating to coalescing where things
go wrong (altough _probably_ not in exploitable way) if one tries to
change auth.


-Ilari
Received on Tuesday, 20 October 2015 06:28:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC