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

[Martin Rex <[e-mail]>]

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