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

After an offline discussion with Martin I think we really should remove
the sentence " The client MAY omit the extension..." Omitting the
extension seems like a really bad idea, because if the session is not
resumed the client may establish a session with different
characteristics than what was intended. So now we have:

"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. When
resuming a session, the server MUST NOT include a server_name extension
in  the server hello." 

I think it is also worthwhile to include the guidance from section
7.4.1.4 in RFC 5246 in the paragraph at the end of section 1.1.:

"Note also that all the extensions defined in this document are
relevant only when a session is initiated.  A client that requests
session resumption does not in general know whether the server will
accept this request, and therefore it SHOULD send the same extensions as
it would send if it were not attempting resumption. When a client
includes  one or more of the defined extension types in an extended
client  hello while requesting session resumption:

	-  The server name indication extension MAY be used by the 
         server when deciding whether or not to resume a session 
         as described in section 3.

      -  If the resumption request is denied, the use of the extensions
         is negotiated as normal.

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

Joe

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> Joseph Salowey (jsalowey)
> Sent: Thursday, May 20, 2010 2:22 PM
> To: mrex@sap.com
> Cc: tls@ietf.org
> Subject: Re: [TLS] Text for draft-ietf-tls-rfc4366-bis
> 
> 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:mrex@sap.com]
> > Sent: Thursday, May 20, 2010 11:11 AM
> > To: Joseph Salowey (jsalowey)
> > Cc: ietfc@btconnect.com; tls@ietf.org
> > 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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls