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

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 7 Oct 2005 16:39:41 -0700

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

---

From: Rob Dugal <[email-masked]>
Date: Wed, 12 Oct 2005 10:34:13 -0400

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