Re: Coalescing and Connection Management

TLS chairs, could we get your WG’s 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.

Thanks,



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 editor’s 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