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

[Martin Rex <[e-mail]>]

Joseph Salowey 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.

I would really like to you distinguish the details more carefully.

"ignored when resuming a session" is something that applies
_after_ the server's decision to resume a proposed TLS session.


>
>                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.

It is just the opposite.  If a Server _supports_ SNI, it ought to make
the chosen value from the previous handshake part of the cached TLS session,
and re-validate any SNI values supplied by the client in ClientHello
on every session resumption.


>
> 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.

Full agreement here.


>
> The client should not attempt to use a different SNI in the
> resumption as it is ambiguous.  

Although I'm also in full agreement on the client's behaviour,
this ought not to have any relevance for the server's decision.
The server is supposed to act on data that is actually present in
ClientHello.  The server should not try to guess what the client
may have desired and potentially mis-represented in ClientHello params.

> 
> 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'd like to see instead something more like this:

"If a server implements _and_ confirms the use of a server_name extension
 proposed by a TLS client on a full TLS handshake, then the server MUST
 validate the contents of the server_name extension on all attempts of
 the TLS client to later resume this TLS session from the TLS session
 cache in an abbreviated handshake.  If a validation is necessary,
 and that validation fails, the server MUST perform a full TLS handshake.

 TLS clients that want to propose TLS session resumption, SHOULD provide
 the same parameters in ClientHello (including TLS extensions) as in the
 original handshake, because the server is supposed to validate these
 parameters against the characteristics of the cached session from the
 original full TLS handshake, and the server is supposed to perform
 a full TLS handshake instead of a TLS session resumption if that
 validation of the ClientHello parameters determines that it will
 result in a TLS session with different characteristics."

-Martin