- From: Jason T. Greene <jason.greene@redhat.com>
- Date: Tue, 20 Oct 2015 08:31:05 -0400 (EDT)
- To: Ilari Liusvaara <ilariliusvaara@welho.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
> On Oct 20, 2015, at 1:33 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote: > >> 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]). Wouldn't the semantics be a hell of a lot cleaner, and implementations a lot simpler, if we just pushed this to an HTTP cert auth protocol? Having two different TLS solutions which in and of themselves are brittle sounds like a recipe for security vulnerabilities and broken interop.
Received on Tuesday, 20 October 2015 12:31:33 UTC