W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Coalescing and Connection Management

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 12 May 2014 13:11:34 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Rob Trace <Rob.Trace@microsoft.com>
Message-Id: <45864E15-7E8C-4FDE-9229-0E1BB8C4B078@mnot.net>
To: Eric Rescorla <ekr@rtfm.com>, Sean Turner <turners@ieca.com>, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
TLS chairs, could we get your WGs perspective on this?

I note that the same section says earlier:

> If there is a mismatch between the server name used
> by the client application and the server name of the credential
> chosen by the server, this mismatch will become apparent when the
> client application performs the server endpoint identification, at
> which point the client application will have to decide whether to
> proceed with the communication.


On 12 Apr 2014, at 7:52 am, Rob Trace <Rob.Trace@microsoft.com> wrote:

> We have been doing some internal investigations and it looks like we have scenarios that require TLS client auth.  Based on this, we took another look at the current editors draft, and it appears that the spec creates a conflict between the [TLS-EXT] spec and coalescing.  Essentially, coalescing to multiple server names violates section 3, RFC 6066 [TLS-EXT] where it states:
> If the server_name is established in the TLS session handshake, the client SHOULD NOT attempt to request a different server name at the application layer.
> Because of this, we have two SHOULD NOT statements that clearly contradict each other and now cause complication for existing HTTP deployments.  The original text of section 9.1 was that we were encouraging clients to follow the same origin policy which would avoid these problems.  The new text in section 9.1 actually discourages implementations from following the same origin policy. 
> My proposal is the following:
> 1.       Discourage coalescing. This is especially true for TLS connections in order to reuse TLS and SNI as defined and implemented.  This also follows the principle from the charter of maintaining existing HTTP semantics.
> 2.       If an implementation is doing #1 then we can leave client auth as is and we do not need to disallow HTTP/2 for scenarios that require it today.
> 3.       Refer the discussion of coalescing, removing renegotiation and client auth to the TLS working group.  Maybe it is something that can be addressed in TLS 1.3.
> Thanks!!
> -Rob

Mark Nottingham   http://www.mnot.net/
Received on Monday, 12 May 2014 03:12:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC