Subject: RE: [TLS] draft-salowey-tls-ticket-05.txt available

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 17 Nov 2005 09:05:35 -0800

Hi Rob,

I have been trying to catch up on this discussion.  You are right, we
modified the draft to allow the server to send a SessionTicket handshake
message during session resume.  It seems that this is an issue for DTLS
because you don't know if you should receive this message or not. If
this is the problem I can see two ways to fix this in the draft.  

In the first approach we can disallow the sending of a new session
ticket on session resume.  

The second approach would be to have the server send a session ticket
extension whenever it thought it might issue a ticket.  If it did then
it would be required to include a session ticket handshake message in
the exchange (the message might have zero length if for some reason the
server decides not to send a ticket).

This extension really should work with DTLS so I think we need to do one
of the above. I think the second approach would be better (the first one
is probably incomplete with the second one anyway).  Always require the
server to send a sessionTicket extension if it may need to issue a
session ticket in the handshake.  If the server includes the extension
then it MUST send a session ticket handshake message.  The handshake
message may be 0 length if the server couldn't issue a ticket for some
reason.  

Make sense?

Thanks,

Joe

> -----Original Message-----
> From: Rob Dugal [mailto:[email-masked]] 
> Sent: Thursday, November 17, 2005 4:36 AM
> To: Salowey, Joe
> Cc: [email-masked]; [email-masked]
> Subject: Re: [TLS] draft-salowey-tls-ticket-05.txt available
> 
> 
> During a discussion of TLS with Eric Rescorla  I brought up 
> your draft and it turns out Eric and I have interpreted 
> session resumption in section 3.1 a little differently. 
> I have pasted a portion of the discussion below. 
> 
> > > >          ClientHello 
> > > >          (SessionTicket extension)      --------> 
> > > >                                                         
>   ServerHello 
> > > >                                                         
> SessionTicket 
> > > >                                                    
> [ChangeCipherSpec] 
> > > >                                        <--------        
>      Finished 
> > > >          [ChangeCipherSpec] 
> > > >          Finished                      --------> 
> > > >          Application Data              <------->     
> Application Data 
> > > 
> > > I don't read this the same way as you do. The way I read 
> it is that 
> > > the SessionTicket is the signal that the server wishes to 
> resume. If 
> > > it's not sent, the server does a full handshake.
> > 
> > We will have to get Joe Salowey to clarify this because he 
> also states: 
> >         "If the server successfully verifies the client's 
> ticket then it may renew the 
> >        ticket by including a SessionTicket handshake 
> message after the ServerHello." 
> > 
> > To me "may renew the ticket" implies that the SessionTicket is 
> > optional but that resumption can still take place.
> 
> From my reading of your draft-05 I came to the conclusion 
> that there are 2 possible sets of messages if session 
> resumption takes place using the client's ticket. 
> 
> case 1: where the server resumes but also issues a new ticket: 
> 
>           ClientHello 
>           (SessionTicket extension)      --------> 
>                                                            
> ServerHello 
>                                                          
> SessionTicket 
>                                                     
> [ChangeCipherSpec] 
>                                         <--------             
> Finished 
>           [ChangeCipherSpec] 
>           Finished                      --------> 
>           Application Data              <------->     
> Application Data 
>                                                            
> ServerHello 
> 
> 
> case 2: where the server resumes but does not issue a new ticket: 
> 
>           ClientHello 
>           (SessionTicket extension)      --------> 
>                                                            
> ServerHello 
>                                                     
> [ChangeCipherSpec] 
>                                         <--------             
> Finished 
>           [ChangeCipherSpec] 
>           Finished                      --------> 
>           Application Data              <------->     
> Application Data 
>                                                            
> ServerHello 
> 
> could you please clarify?
> -----------------------------------------------
> 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/24/2005 01:43:07 PM:
> 
> > draft-salowey-tls-ticket-05.txt is available at
> > 
> > http://www.ietf.org/internet-drafts/draft-salowey-tls-ticket-05.txt
> > 
> > changes based on review comments:
> > 
> > - Section 3.4 added to describe interaction with session ID
> > - Section 4 now indicates recommended format instead of example
> > - Sections 3.2 and 3.3 behavior of messages clarified
> > 
> > Thanks,
> > 
> > Joe
> > 
> > _______________________________________________
> > 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, 17 Nov 2005 12:19:08 -0500

I like the second approach.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Nov 2005 16:15:03 -0800

> message may be 0 length if the server couldn't issue a ticket for some

This works for me.

-Ekr