Re: [TLS] Text for draft-ietf-tls-rfc4366-bis

["Joseph Salowey (jsalowey)" <[e-mail]>]

Hi Martin,

Thanks, I think I captured your suggestion below.  

"When the server is deciding whether or not to accept a request to
resume a session, the contents of a server_name extension MAY be used in
the lookup of the session in the session cache.  The client SHOULD
include the same server_name extension in session resumption request as
it did in the full handshake that established the session.  A server
that implements this extension MUST NOT accept the request to resume the
session if the server_name extension contains a different name.
Instead, it proceeds with a full handshake to establish a new session.
The client MAY omit the extension, in which case, if  the server chooses
to resume the session, it must use the server name cached from the
original full handshake. When resuming a  session, the server MUST NOT
include a server_name extension in  the server hello."

> -----Original Message-----
> From: Martin Rex [mailto:[e-mail]]
> Sent: Thursday, May 20, 2010 11:11 AM
> To: Joseph Salowey (jsalowey)
> Cc: [e-mail]; [e-mail]
> Subject: Re: [TLS] Text for draft-ietf-tls-rfc4366-bis
> 
> Joseph Salowey wrote:
> >
> > Good suggestion, thanks for the text, here is the text reworked:
> >
> > "When the server is deciding whether or not to accept a request to
> >  resume a session, the contents of a server_name extension may be
used
> >  in the lookup of the session in the session cache.  The client
SHOULD
> >  include the same server_name extension in session resumption
> >  request as it did in the full handshake that established the
> >  session.  If the server_name extension contains a different name,
> >  the server MUST NOT accept the request to resume the session.
> >  Instead, it proceeds with a full handshake to establish a new
> >  Session.  The client MAY omit the extension, in which case, if
> >  the server chooses to resume the session, it must use the server
> >  name cached from the original full handshake. When resuming a
> >  session, the server MUST NOT include a server_name extension in
> >  the server hello."
> 
> The requirements appear somewhat imbalanced to me.
> In order to conform to the requirement
> 
>    If the server_name extension contains a different name,
>    the server MUST NOT accept the request to resume the session.
> 
> every server must (a) implement server_name extension and (b)
> memorize the content from the initial handshake in the TLS session
> cache.  At that point the "may be used in the lookup of the session"
> effectively becomes a MUST be used in the lookup of the session,
> because the contents will always have to be verified before agreeing
> a session resumption, even if the server_name contents isn't
> technically used as a "lookup key" into the cache.
> 
> 
> This MUST NOT would need to be scoped to the implementors of the
> "MAY be used in the lookup of the session", and the MAY in the
> first sentence probably be uppercased.
> 
> 
> From the architecture point of view, I see the following issues
> to consider about interaction of ClientHello parameters and
> session resumption:
> 
>  -  ClientHello parameters from the session resumption request
>     MUST NOT affect the session within the session cache at all
>     (except possibly deleting the session on a failed resumption)
> 
>  -  ClientHello parameters from the session resumption request
>     MUST affect connection parameters only in documented fashion
>     (derivation of keying material e.g. through additional PRF input,
>      renegotiation_info extension)
> 
>  -  ClientHello parameters MUST be checked for compatibility with
>     the characteristics of the cached session before resumption,
>     but this check is limited to those parameters that the server
>     actually implements/supports.
> 
>  -  In addition, a server may decide that ClientHello parameters
>     provides characteristics that the server would prefer over the
>     characteristics of the cached session and go for a full handshake
> 
> 
> -Martin