Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 12 Oct 2005 09:17:25 -0700

In the proposed text the client can generate a session ID for inclusion
in the ClientHello with the SessionTicket extension.  If the server
returns the same Session ID in the ServerHello the client knows the
server is resuming the session based on the ticket in the SessionTicket
extension.  This should address part of your concern.  

To address whether the server will issue a SessionTicket handshake
message the server could include an empty SessionTicket extension in the
ClientHello when it plans to send the SessionTicket handshake message.
I am reluctant to do this because the Server may not know at the time of
the ServerHello if it will issue a ticket for a full handshake.  

Joe 

> -----Original Message-----
> From: Rob Dugal [mailto:[email-masked]] 
> Sent: Wednesday, October 12, 2005 7:34 AM
> To: Salowey, Joe
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt
> 
> 
> Although it is possible for the client to determine if the 
> server is resuming by looking at the messages received, the 
> client state machine would be easier to implement if you 
> provided some indicator in the ServerHello message. If you 
> include an extension in the ServerHello that indicates the 
> server will resume then the client state machine will know 
> exactly what msgs the server should send next. You could also 
> indicate in the extension if the server will resume but also 
> issue a new ticket which would then make it very clear to the 
> client what msgs must come from the server. 
> 
> -----------------------------------------------
> Robert Dugal
> Member of Development Group
> Certicom Corp.
> EMAIL: [email-masked]
> PHONE: (905) 501-3848
> FAX  : (905) 507-4230
> WEBSITE: www.certicom.com 
> 
> [email-masked] wrote on 10/07/2005 07:39:41 PM:
> 
> > Here is some proposed test that I think resolves the issues with 
> > session ID raised by Rob and Nelson:
> > 
> >    "If a server is planning on issuing a SessionTicket to a 
> client that
> >    does not present one it SHOULD include an empty Session ID in the
> >    ServerHello.  If the server includes a non-empty session 
> ID then it
> >    is indicating intent to use stateful session resume.  If 
> the client
> >    receives a SessionTicket from the server then it 
> discards any Session
> >    ID that was sent in the ServerHello.
> > 
> >    When presenting a ticket the client MAY generate and 
> include Session
> >    ID in the TLS ClientHello.  If the server accepts the 
> ticket and the
> >    Session ID is not empty then it MUST respond with the 
> same Session ID
> >    present in the ClientHello.  This allows the client to easily
> >    differentiate when the server is resuming a session or 
> falling back
> >    to a full handshake.  Since the client generates a Session ID the
> >    server MUST NOT rely upon the Session ID having a 
> particular value
> >    when validating the ticket.  If a ticket is presented by 
> the client
> >    the server MUST NOT attempt to use the Session ID in the 
> ClientHello
> >    for stateful session resume.  Alternatively, the client 
> MAY include
> >    an empty Session ID in the ClientHello.  In this case the client
> >    ignores the Session ID sent in the ServerHello and must 
> determine if
> >    the server is resuming a session by the subsequent handshake
> >    messages."
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Thursday, October 06, 2005 7:23 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt
> > > 
> > > Rob Dugal wrote:
> > >    
> > > > Actually having a ticket doesn't guarantee the server 
> will later 
> > > > resume with it.
> > > >
> > > > For example, the ticket could be old and the server might
> > > not want to
> > > > use it.  My concern is that without knowing that the 
> server will 
> > > > resume using the ticket it get's a little difficult to 
> know what 
> > > > handshake messages the server will respond with. When 
> the server 
> > > > resumes with the sessionID it is pretty clear because 
> the server 
> > > > returns the same sessionID in the ServerHello as the 
> client sent 
> > > > in the ClientHello. But in TLS ticket there is no clear
> > > indication from
> > > > the ServerHello that the server will resume. And now there
> > > is also the
> > > > proposal for allowing the server to send NewSessionTicket
> > > on a resumed
> > > > session.
> > > 
> > > Hmm.. I agree, it would be nice to have an unambiguous 
> signal in the 
> > > ServerHello that tells the client resumption is happening.
> > > This would be the case if we also included the normal 
> sessionID as I 
> > > suggested earlier in
> > > 
> > > http://www.imc.org/ietf-tls/mail-archive/msg04709.html
> > > 
> > > > Which also brings up the question: what does the server 
> do if it 
> > > > receives an invalid ticket, such as a forged ticket? 
> Does it just 
> > > > ignore the ticket? Send an alert?
> > > 
> > > Same thing it does when it receives an invalid session ID:
> > > ignores it and starts a full handshake.
> > > 
> > > Best regards,
> > > Pasi
> > > 
> > > _______________________________________________
> > > TLS mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/tls
> > > 
> > 
> > _______________________________________________
> > TLS mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tls
> 
> 

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Rob Dugal <[email-masked]>
Date: Wed, 12 Oct 2005 16:38:55 -0400

> ClientHello when it plans to send the SessionTicket handshake message.
 I think you meant to say ServerHello here.

> the ServerHello if it will issue a ticket for a full handshake. 

I just realized that resuming with a Ticket and sending a ServerHello with 
an extension would not comply with this statement from RFC 3546, section 
2.3.

If, on the other hand, the older
   session is resumed, then the server MUST ignore extensions appearing
   in the client hello, and send a server hello containing no
   extensions; in this case the extension functionality negotiated
   during the original session initiation is applied to the resumed
   session.

So my earlier suggestion is probably not allowable.