Subject: RE: [TLS] Revised sections 3.2 and 3.3 from draft-salowey-tls-ticket

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 14 Dec 2005 11:53:47 -0800

Hi Rob,

The current text in section 3.4 allows the client know whether the
server will resume based on the contents of the ServerHello.  If the
server returns back the sessionID that the client sent in the
ClientHello the the client know the server is resuming the session.
This achieves the same result as including flags in the SessionTicket
extension in the ServerHello.  I think that section 3.4 along with the
latest modification make it clear what handshake messages the client and
server are expected to send and receive. 

The text is included below, let me know if there is something incorrect
or not clear about it. 

3.4  Interaction with TLS session ID

   "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 a
   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 determines
   if the server is resuming a session by the subsequent handshake
   messages."

Thanks,

Joe

> -----Original Message-----
> From: Rob Dugal [mailto:[email-masked]] 
> Sent: Wednesday, December 14, 2005 7:29 AM
> To: Salowey, Joe
> Cc: Eric Rescorla; [email-masked]; [email-masked]; bminard
> Subject: Re: [TLS] Revised sections 3.2 and 3.3 from 
> draft-salowey-tls-ticket
> 
> 
> I don't see any problem with the proposed revision. However, 
> I still think the draft could be improved and I don't think 
> the SessionTicket extension can be efficiently supported in 
> DTLS because of how DTLS handles the ChangeCipherSpec message. 
> 
> As I have stated previously on this list I do not like the 
> SessionTicket draft for one fundamental reason. The client 
> does not know that the server is resuming using a ticket 
> unless it receives the ChangeCipherSpec message immediately 
> after the ServerHello. This is not true with regular session 
> resumption. The client knows the server is resuming by a 
> non-empty session id in the ServerHello. With regular session 
> resumption the client desn't have to look at what message 
> arrives next to determine if it is resuming. Because of this 
> when we implemented SessionTicket in our TLS implementation 
> we had to make the handshake state machine more complex. The 
> proposed change will allow us to somewhat simplify our state 
> machine implementation but it will still be less than ideal 
> in my opinion. Your proposed change only indicates if a new 
> ticket will be issued, not whether the server will resume or 
> not. I would prefer that the ServerHello contain something to 
> clearly indicate that the server is resuming using the 
> SessionTicket. This could be done by adding an extension to 
> the ServerHello and have the extension contain some flags 
> that indicate if the session will be resumed and if a new 
> ticket will be issued. Note: this might not be permitted in 
> RFC3546 because I think it says that the extensions in the 
> ServerHello should be empty.   
> 
> As I have stated previously on this list I do not like the 
> DTLS draft because of how it handles the ChangeCipherSpec 
> message. In DTLS only handshake messages have a message 
> sequence number (MSN). The MSN allows the DTLS record layer 
> to determine if handshake messages have been lost and their 
> correct order. However, the ChangeCipherSpec does not have an 
> MSN. Since the CCS always preceeds the Finished message we 
> can only determine it's correct position by decrypting the 
> Finished message. Decrypting the Finished message requires 
> that the handshake layer has already derived the read/write 
> keys from the master secret. If the ChangeCipherSpec message 
> had an MSN then determining it's position in relation to 
> handshake messages would be trivial and would not require 
> decrypting the Finished message.  It is interesting to note 
> that the co-author of the DTLS draft wrote the openssl 
> implementation of DTLS and incorrectly coded the 
> ChangeCipherSpec message to contain an MSN. I will be 
> interested in seeing how he resolves this problem in openssl 
> because it caused me some headaches in our own DTLS implementation. 
> 
> In a normal DTLS handshake, when the client receives the 
> ServerHello with a session id it knows the server is 
> resuming, retrieves the saved session state and generates the 
> read/write keys from the master secret. It is then possible 
> to decrypt the Finished message when it arrives and find out 
> the correct position of the CCS. 
> 
> In a SessionTicket DTLS handshake when the client receives 
> the ServerHello it doesn't know if the server is resuming 
> using the ticket. So what should it do? Should the client 
> always assume the ticket will be resumed and generate the 
> read/write keys from the master secret? If It does this and 
> the server then decides to instead do a full handshake then I 
> just wasted time generating the read/write keys. That's not 
> ideal in my opinion. 
> 
>   
> 
> -----------------------------------------------
> 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 12/13/2005 12:07:58 PM:
> 
> > Below are the sections from the tls ticket draft that 
> should fix the 
> > issue with DTLS.  The server is now required to send a 
> SessionTicket 
> > handshake extension if it is going to send a SessionTicket 
> handshake 
> > message.  Let me know if this looks OK.
> > 
> > Thanks,
> > 
> > Joe
> > 
> > 3.2  SessionTicket TLS extension
> > 
> >    The SessionTicket TLS extension is based on [I-D.ietf-tls-
> >    rfc3546bis].  The format of the ticket is an opaque 
> structure used to
> >    carry session specific state information.  This 
> extension may be sent
> >    in the ClientHello and ServerHello.
> > 
> >    If the client posses a ticket that it wants to use to resume a
> >    session then it includes it in the SessionTicket extension in the
> >    ClientHello.  If the client does not have a ticket and 
> it is prepared
> >    to receive one in the SessionTicket handshake message 
> then it MUST
> >    include a zero length ticket in the SessionTicket 
> extension.  If the
> >    client is not prepared to receive a ticket in the SessionTicket
> >    handshake message then it MUST NOT include a 
> SessionTicket extension
> >    unless it is sending a non-empty ticket it received through some
> >    other means from the server.
> > 
> >    The server uses an zero length SessionTicket extension 
> to indicate to
> >    the client that it will send a new session ticket using the
> >    SessionTicket handshake message described in Section 
> 3.3.  The server
> >    MUST send this extension in the ServerHello if the 
> server wishes to
> >    issue a new ticket to the client using the SessionTicket 
> handshake
> >    message.  The server MUST NOT send this extension if the 
> client does
> >    not include a SessionTicket handshake message in the 
> client hello.
> > 
> >    If the server fails to verify the ticket then it falls back to
> >    performing a full handshake.  If the ticket is accepted 
> by the server
> >    but the handshake fails the client SHOULD delete the ticket.
> > 
> >    The SessionTicket extension has been assigned the number 
> TBD1.  The
> >    format of the SessionTicket extension is given below.
> > 
> > 
> > < skip ticket format definition >
> > 
> > 
> > 3.3  SessionTicket handshake message
> > 
> >    This message is sent by the server during the TLS 
> handshake before
> >    the ChangeCipherSpec message.  This message MUST be sent if the
> >    server included a SessionTicket extension in the 
> ServerHello.  This
> >    message MUST NOT be sent if the server did not include a
> >    SessionTicket extension in the ServerHello.  In the case 
> of a full
> >    handshake, the server MUST verify the client's Finished message
> >    before sending the ticket.  The client MUST NOT treat 
> the ticket as
> >    valid until it has verified the server's Finished 
> message.  If the
> >    server determines that it does not want to include a 
> ticket after it
> >    has included the SessionTicket extension in the 
> ServerHello then it
> >    MAY send a zero length ticket in the SessionTicket 
> handshake message.
> > 
> >    If the server successfully verifies the client's ticket 
> then it MAY
> >    renew the ticket by including a SessionTicket handshake 
> message after
> >    the ServerHello in the abbreviated handshake.  The client should
> >    start using the new ticket as soon as possible after it 
> verifies the
> >    Server's finished message for new connections.  Note 
> that since the
> >    updated ticket is issued before the handshake completes it is
> >    possible that the client may not put the new ticket into 
> use before
> >    it initiates new connections.  The server MUST NOT 
> assume the client
> >    actually received the updated ticket until it 
> successfully verifies
> >    the client's Finished message.
> > 
> >    The SessionTicket handshake message has been assigned the number
> >    TBD2.  The definition of the SessionTicket handshake 
> message is given
> >    below.
> > 
> > _______________________________________________
> > 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: Thu, 15 Dec 2005 07:35:01 -0500

Thanks Joe, I now see how section 3.4  allows the client to determine from 
the ServerHello if the ticket will be resumed.
This addresses all my concerens and I think we can also add the extension 
to our DTLS implementation.