Re: [TLS] Proposed changes to draft-ietf-tls-rfc4366-bis

[Michael D'Errico <[e-mail]>]

Joseph Salowey (jsalowey) wrote:
> I do not think the behavior that Mike describes is strictly compliant
> with RFC 4366 as it states that the SNI should be ignored when resuming
> a session.

Right.  And I think that statement is a problem which should be
clarified.

> From an interop point of view I think it is important to
> clarify that the server does not use the SNI extension in the look-up
> the session ID in the session cache.  If the session is resumed and
> client presents an SNI extension in the resumption attempt it should get
> the same result as if it did not.  The client should not attempt to use
> a different SNI in the resumption as it is ambiguous.  

I agree that the client should not attempt to use a different SNI when
resuming a session.  In fact I'd say it MUST NOT.

But when a server is presented with an SNI and a cached session, why
wouldn't the server be allowed to check for consistency?  In fact, by
restricting a server to not be allowed to check, you are compromising
the security of the domain listed in the SNI.

> How about the following text:
> 
> "When the server resumes a session, the server_name extension is ignored
> and not used in the lookup of the session in the session cache.  If the
> session is resumed, the server will always use the server name
> associated with the cached session. The server MUST NOT include a
> server_name extension in the server hello. When resuming a session the
> client MUST NOT use a different server name than the one used in
> establishing the original session.  The client MAY omit the server_name
> extension during session resumption. " 

I think part of the problem is that you are viewing SNI as an optional
feature useful only for convenience.  In my software it is critical to
the entire operation.  You can set up any number of virtual servers,
each of which has its own collection of certificate chains and keys,
options (such as whether to allow renegotiation, whether to request a
client certificate, etc.), and a list of domain names that map to the
virtual server.

When the SNI is received, it is used to figure out which virtual server
the client wants to connect to.  Once the particular virtual server is
chosen, all of the parameters including list of allowed cipher suites
and other options are installed.

So when a client offers to resume a session for one of my virtual
servers, but has also included an SNI for a different virtual server,
it is clear that it's either a mistake or possibly even malicious.

In my code, I've decided that the SNI is more important, so the session
is not resumed even if it is still in the session cache.  Thus a full
handshake occurs using the SNI from the client hello, and the client
ends up talking to the correct virtual server.

Mike



> Joe
> 
>> -----Original Message-----
>> From: Martin Rex [mailto:[e-mail]]
>> Sent: Monday, May 17, 2010 6:22 AM
>> To: Joseph Salowey (jsalowey)
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: [TLS] Proposed changes to draft-ietf-tls-rfc4366-bis
>>
>> Joseph Salowey wrote:
>>> This clarification is consistent with existing text in the draft and
> in
>>> RFC 4366.
>> The way it is written appears somewhat misleading, and the resulting
>> change to 4366 indicates that we need to come up with a better
>> description.
>>
>>> " Note also that all the extensions defined in this section are
>>>    relevant only when a session is initiated. ...
>>>
>>> -  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."
>>>
>>> Michael D'Errico wrote:
>>>>    Add to section 3 before the last paragraph to clarify session
>>>>    resumption behavior:
>>>>
>>>>    "When the server resumes a session, the server_name extension
>>>>    is ignored."
>>>>
>>>> I have not yet done it, but I plan to have my session resumption
>>>> logic look at the SNI to see if it matches the name used for the
>>>> cached session.  If they don't match, a full handshake will be
>>>> completed.  We already have to verify that TLS version, cipher
>>>> suite, and compression method are compatible with the hello
>>>> parameters.  I don't see why the SNI is any less important.
>>
>> Your intended behaviour sounds perfectly fine and sensible.
>>
>>>> Does the above text suggest that my plan would be non-compliant?
>>
>> No.  Your intention is to determine whether a suitable cached session
>> exist for resumption.  Once you have determined that, you resume
> without
>> SNI affecting the characteristics of the resumed session.
>>
>>
>> But your confusion suggests that this should probably be rephrased
>> in order clarify what is meant.
>>
>>
>> There are two entirely seperate issues that ought to be distinguished.
>>
>> (1) criteria which the server considers in his decision whether to
>>     resume a TLS session from the cache by performing an abbreviated
>>     TLS handshake for the TLS session ID proposed by the TLS client in
>>     the ClientHello handshake message.
>>
>> (2) effects of parameters in ClientHello (regular or through
> extensions)
>>     on the characteristics of the established TLS session.
>>
>>
>> What Joe an the new text says is only about (2).  When the server
> decides
>> to resumt a TLS session from cache, then it must be resumed as-is,
> none
>> of the parameters or extensions in the ClientHello is allowed to
> modify
>> the characteristics of the resumed TLS session.
>>
>>
>> (1) is a totally different beast.  Whether or not the server resumes a
>> TLS session proposed by the TLS client is completely at the
>> discretion of the server.  IMHO, it makes perfect sense for the
>> server to check whether the attributes that the client requests
>> through all those parameters in regular ClientHello plus TLS extension
>> actually match the characteristics of proposed cached session,
>> and to go through a full TLS handshake if they don't.
>> A server can also expire a session from his session cache whenever
>> it sees a need to do so.
>>
>>
>> In some implementations, the TLS session cache may be shared among
>> several processes on a host, not just a single application that tries
>> to offer virtual hosting with TLS through the server name indication
> (SNI)
>> TLS extension.  That correct client implementations shouldn't be
>> proposing to resume TLS sessions across "virtual hosts" boundaries is
>> not relevant for the server's decision.  The server should not try to
>> make any assumptions on client desire or behaviour, but instead act
>> deterministically based on the parameters in the supplied ClientHello
>> handshake message.
>>
>>
>>
>> -Martin
>