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

[Nelson B Bolyard <[e-mail]>]

On 2009-10-29 16:26 PDT, Martin Rex wrote:
> Nelson B Bolyard wrote:
>> 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,
> 
> That client is obviously broken.

Perhaps, but the question is what does the server do about it?

>> 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.
> 
> If the server supports virtual hosting through SNI, 

that's a given for this exercise

> it should look up the session ID of the client only in the session cache 
> associated with the hostname A.

And it should choose hostname A because why?  Remember that in the above
example, the SNI bears host name B.

> If a TLS session resume proposal with [an] SNI for B arrives,
> there will be no cached session with that session ID in the
> TLS session cache tied to credential for A, so it must result
> in a full TLS handshake.

So, you're proposing that the server should look in the SNI first to see
which host name is there, and use that info to decide which virtual host's
server session cache to examine for the numbered session?  In other words,
each virtual host has its own separate session cache with fully overlapping
spaces of session ID numbers, disambiguated by the SNI host name, yes?
In this model, an SNI would be absolutely required to resume a session that
had been established with an SNI, yes?


> A server that has different credentials for A and B (and would
> use them based on SNI 

The whole point of SNI is to have different credentials for different
virtual hosts.  If you don't have different credentials for different
virtual hosts, (e.g. if you have a single certificate for all your
virtual hosts) then you don't need SNI.

> is definitely broken if it agrees to a proposed resume of a session
> originally established with A in a ClientHello that carries an SNI for B,
> because the server knows exactly that the server certificate that the
> client has for this session is NOT the same certificate that the server 
> would send in a full handshake for B.

This objective could be accomplished with a single server session cache
that covered the entire physical server and all its virtual servers, IF
the server compared the host name in the SNI with the host name associated
with the session in the cache.  But I see that your proposal definitely
gives precedence to the SNI.  This is quite different than Mick's answer.