Coalescing and Connection Management

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