Re: [TLS] Requiring SNI for resumption (was Questions about TLS Server Name Indication extension)

I think that it would be a good change to require a client to include the
same SNI extension when resuming a session.  The complexity of my code to
find a session among multiple session caches is far greater than it would
have been if I could have relied on the hostname from SNI.

RFC 4366 currently disallows using SNI to resume:

    -  If, on the other hand, the older session is resumed, then the
       server MUST ignore the extensions and send a server hello
       containing none of the extension types.  In this case, the
       functionality of these extensions negotiated during the original
       session initiation is applied to the resumed session.

I'd be in favor of changing RFC 4366 to mandate providing the same SNI when
resuming a session, if nothing will break because of it.

Mike

Nelson B Bolyard wrote:
> 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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 