Re: [TLS] Questions about TLS Server Name Indication extension

[Nelson B Bolyard <nelson at bolyard.me>]

On 2009-10-28 12:30 PDT, Wan-Teh Chang wrote:
> On Wed, Oct 28, 2009 at 10:35 AM, Nelson B Bolyard <nelson at bolyard.me> wrote:
>> In the context of a physical server acting as multiple virtual server,
>> is the space of session IDs coming from that server a single space that
>> encompasses all the sessions for all the virtual servers served by that
>> physical server?  Or does each virtual server have its own separate space?
>>
>> If each virtual server has its own separate session ID space, then when
>> attempting to "resume" or "restart" a TLS session, the client hello MUST
>> bear an SNI extension to inform the physical server which virtual server's
>> session ID space contains the given session ID, and each virtual server
>> potentially has its own separate session store/cache.
> 
> When attempting to resume a TLS session, the client hello must
> bear an SNI extension for another reason: it's not guaranteed that
> the server will accept the request to resume the session.  This issue
> is discussed in Section 2.3 of the TLS extensions RFC 3546.  (The
> RFC uses SHOULD instead of MUST.)
> 
>> OTOH, if there is a single session ID space for the entire physical server
>> covering all the virtual servers, then each cached session must record and
>> identify the virtual server with which it is associated.

There's another issue that arises with both the SNI extension and a single
session ID space for the entire physical server.  Which takes precedence?

Consider this scenario:
Physical host has two virtual hosts, A and B.
First handshake:
  client sends SNI with host name A, empty session ID.
  server does full handshake, session ID 1.
Second handshake (renegotiation):
  client sends SNI with host name B and session ID 1,

Session ID 1 implicitly identifies host A.

The server could
A)  Honor the session ID and ignore the SNI.
B)  Compare the host name in the SNI with the host name for session ID 1,
    observe the mismatch, and do a new FULL handshake for host B.
C)  Compare the host name in the SNI with the host name for session ID 1,
    observe the mismatch, and return a fatal error alert.

RFC 5246 seems to suggest choice A.  It says:

   Most current TLS extensions are relevant only
   when a session is initiated: when an older session is resumed, the
   server does not process these extensions in Client Hello, and does
   not include them in Server Hello.

But I tend to lean towards choice B myself.

What do other SNI server implementations do in this case?