Permit/Forbid Coalescing

[martinthomson]

Several of the comments in #363 note that a lot of the issues we have with renegotiation are as a result of a coalescing feature.

This is the not-fully-formally-accepted feature where a client can use an existing connection to a server for different origins.

To recap, coalescing occurs when a client discovers that they have an existing connection to the same IP and port that a URL resolves to. AND the existing connection has a valid certificate for the name that is being sought.

Rob notes the prohibition in Section 3 of RFC 6066 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.

[martinthomson]

If we intend to keep this, then we need to have some fairly strong security considerations regarding having mutually distrustful entities on the same connection.

[martinthomson]

Discussed in NYC; Aside from security considerations, we need a way for a server to foreswear knowledge of a given host/origin and require the creation of a new connection. We need to talk to folks in the TLS WG and we have to allow them to block this feature.

If we proceed, we need to s/SHOULD/MAY/ regarding this, and add context that discourages its use without a good understanding.

We discussed, but will not add, the addition of a setting to signal that coalescing is not supported by the server.

[mnot]

Discussed in NYC;

• Coalescing is a MAY
• need security considerations around risks
• need status code to say "Not Authoritative"
• need review by TLSWG
• future extension to say "this connection doesn't coalesce" might be interesting