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

From: "Salowey, Joe" <[email-masked]>
Date: Tue, 13 Dec 2005 09:07:58 -0800

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

---

From: Rob Dugal <[email-masked]>
Date: Wed, 14 Dec 2005 10:28:50 -0500

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