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

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

> -----Original Message-----
> From: Michael D'Errico [mailto:[e-mail]]
> Sent: Monday, May 17, 2010 9:38 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 (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.
> 
[Joe]  If the server is always going to use the name that is cached then
the name is consistent.  It's not clear that the consistency check adds
anything.  The text below does restrict the client to not change the
SNI, so if you do the consistency check it should not cause interop
problems with compliant clients.   I think we could explicitly allow the
server to perform a consistency check, but that's not quite the same as
the ignore text that is in 4366.   

> > 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.
> 
[Joe] From this description it sounds like we need to make a bigger
change to the section to accommodate this behavior.  What happens if the
client does not present an SNI during resumption?  Will this cause a
problem contacting the correct virtual server?  Is the SNI required by
your implementation during session resumption.  


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