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

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

On 2009-10-30 08:04 PDT, Martin Rex wrote:
> Nelson B Bolyard wrote:
>> 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?
> 
> If the SNI made a difference in the server credential when the session
> was originally created, then the SNI MUST make the same difference
> for resume.  The a requirement for consistency and reproducable behaviour.
> 
> If the SNI did not make a difference when the cached session was
> originally created (e.g. the server doesn't support SNI), then it
> does not need to make a difference on resume.

RFC 5246 says:

   In general, the specification of each extension type needs to
   describe the effect of the extension both during full handshake and
   session resumption.  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.  However, some extensions may
   specify different behavior during session resumption.

You're saying that SNI is not like "Most current TLS extensions" in that
when an older session is resumed, the server DOES process this extension,
and its behavior is NOT different during session resumption than during
session initiation.

I think that's a legitimate and self-consistent proposal, one of several
that I could envision, which is why I raised this subject.  But as we've
seen in this thread, others (e.g. IBM) clearly have implemented a very
different model.

For the sake of interoperability, I think we need to define a single
standard definition to which we all adhere.

> 
>>>> 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?
> 
> Compensate for the broken client and perform a full SSL handshake.

IBM's answer was: ignore the SNI and resume session ID 1 with host A,
which seems to be what RFC 5246 says TLS should do for _most_ TLS hello
extensions.  But I agree that we _could_ *define* SNI to not be like
_most_ TLS hello extensions, if we choose.

> A broken client is no excuse for inconsistent or non-predictable
> server behaviour.  

I agree that, ONCE we all agree that your definition is the right one,
then we agree that the above behavior is that of a broken client.
OTOH, if we end up agreeing that IBM's answer is the right one, then
I don't think we necessarily agree that a client behaving as described above
is necessarily broken.

Regards,
/Nelson