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

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

On 2009-10-28 17:04 PDT, Michael Gray wrote:
> <nelson at bolyard.me> wrote:
> 
>> 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?
> 
> A for IBM native SSL.  The Client SNI data is only processed if the session
> can NOT be resumed.
> 
> Also as an answer to the previous question; we only consider that the
> Client has sent a single name in Client SNI request.

Thanks, Mick, for those concise answers.  Sadly, I don't sense that we
have a consensus from among the responses yet, except on the point that
the SNI client hello should only contain one name of each type.

I think that interoperability demands that we standardize these answers.

I predict that we'll end up with these below(which I think match yours)
but I fear that existing implementations differ from these a fair bit.

- Only one name per type is allowed and used in the client hello SNI.

- The session ID space covers all the sessions for the entire physical host
including all the virtual hosts, so by itself, the session ID contains all
the information necessary to determine which virtual host uses the session
with that ID.  It is not necessary to consult the SNI host name to know
which virtual host's session cache to examine to find the session ID.

- The SNI extension is ignored if the session can be resumed based on the
session ID, and no matching/checking is done to ensure that the SNI host
name matches the name in the resumed session, when the session is resumed.

> Also on previous note <snip> 'because they don't want to send the client
> cert over the wire in the clear" <snip>
> 
> For what reason would you require a client cert or a host name or a host
> certificate to be not treated as public information?  

I don't know.  I work on NSS, an open source TLS library that is used in
lots of applications and is discussed in an open mailing list and newsgroup
(mozilla.dev.tech.crypto).  One of the application developers who uses NSS
has this issue, but I don't know why.  I'd guess it's the usual extreme
security p\a\r\a\n\o\i\a\ precautions that have kept me employed. :)

> Mick Gray
> IBM