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

[Ilari Liusvaara <[e-mail]>]

On Mon, Oct 19, 2015 at 03:10:17PM -0700, Martin Thomson wrote:
> On 23 September 2015 at 10:16, Martin Thomson <[e-mail]> 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