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: Jason T. Greene <jason.greene@redhat.com>
Date: Tue, 20 Oct 2015 08:31:05 -0400 (EDT)
Message-Id: <633F3373-BCB3-4985-ACE7-209F02A167B6@redhat.com>
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

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