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

From: Rob Dugal <[email-masked]>
Date: Wed, 5 Oct 2005 14:27:02 -0400

After sending a client hello containing a TLS Ticket the client doesn't 
really have any idea whether the server will agree to resume using the 
ticket. 
To me it get's a little confusing since several scenarios are possible:
- the server doesn't understand TLS Ticket extension and does a full 
handshake
- the server doesn't understand TLS Ticket extension and resumes using the 
sessionID
- the server resumes using the ticket and doesn't send a sessionID
- the server resumes using the ticket but also sends a sessionID (is this 
allowable?)
- the server decides not to resume using the ticket , does a full 
handshake and sends a new ticket

I think it would simplify client implementation if the server provided 
some indication it intends to proceed with resumption using the client's 
ticket.
What about including an extension in the server hello that would indicate 
to the client that the server will resume using the ticket?

-----------------------------------------------
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 09/30/2005 07:47:14 PM:

> Hi Nelson,
> 
> We had discussed keeping the server side cache mechanism separate from
> the client side cache mechanism when implementing this in case a server
> had some reason for supporting both.  If a server did not want to store
> state then it would send an empty session ID.  The server could decide
> to send both a ticket and session ID if it intended to store state.
> Likewise the client could decide to send both a session ID and ticket,
> then the server could decide which to honor.  If the server returns an
> empty session ID (and continues on to the finished message) it is using
> the ticket, if it returns the session ID then it is using the server
> cache.
> 
> In the case where a client side ticket is used and an implementation
> needed a session ID associated with the ticket it could generate this
> locally as you stated.  For the server this could be stored in the
> ticket, on the client it could be a hash of the ticket.  I'm not sure if
> we should cover this local implementation issue in the spec or not. 
> 
> Joe 
> 
> > -----Original Message-----
> > From: Nelson B. Bolyard [mailto:[email-masked]] 
> > Sent: Thursday, September 29, 2005 5:04 PM
> > To: Salowey, Joe
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [TLS] WG review of draft-salowey-tls-ticket-04.txt
> > 
> > Joe, et. al. TLSers,
> > 
> > My concern about the server sending both a session ID and a 
> > ticket is that it seems to me that when a server sends a 
> > session ID in the server hello, that amounts to a commitment 
> > by the server to restart the session later if the client 
> > sends that session ID in a client hello (within the session 
> > lifetime, and assuming the session has not been invalidated), 
> > even if the client does not present the ticket for that session.
> > 
> > By that reasoning, requiring the server to send a session ID 
> > with the ticket, also obligates the server to keep that 
> > session info in its own session cache, so that it can later 
> > restart that session.  If the server is so obligated, the use 
> > of the ticket does not relieve the server of the burden of 
> > keeping its own copy of the session state.  But it is the 
> > relief of that burden that motivates this entire idea, IMO.
> > 
> > If the server is NOT going to keep a copy of the session 
> > state, and will NOT be able to restart that session later 
> > (unless the client also sends in the ticket), then what is 
> > the value of the server sending that session ID?  To whom is 
> > that non-reusable session ID of value?
> > If the client cannot rely on that session ID for session 
> > restart purposes, then of what value is that session id to the client?
> > 
> > In answer to those questions, it has been suggested to me 
> > that there are TLS implementations that make the TLS session 
> > ID available to the application that uses it, so that the 
> > application can correlate its own data to the TLS session. 
> > It has also been suggested that there MAY be TLS 
> > implementations that allow the applications that use them to 
> > ask the TLS code to restart a specific session by specifying 
> > the session ID.
> > This would suggest a possible use for session IDs, even when 
> > those IDs cannot be used to restart sessions.
> > 
> > However, I think that such applications may already be in 
> > trouble, because the existing TLS RFC does not require TLS 
> > servers to always send a session ID in the server hello.  So 
> > clients that depend on non-empty session ID strings may 
> > already fail with those servers.  Further, the TLS 
> > implementation could offer its own substitute string locally 
> > in such cases.
> > 
> > In order to properly set a client's expectation regarding the 
> > ability to subsequently restart a session based on the 
> > session ID alone, I think it is logical to NOT send the 
> > session ID in the cases where the ticket is required to 
> > subsequently restart the session, and in which the session 
> > cannot be subsequently restarted based on session ID alone.
> > 
> > /Nelson
> > 
> 
> _______________________________________________
> 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: Eric Rescorla <[email-masked]>
Date: Wed, 05 Oct 2005 14:25:14 -0700

> - the server doesn't understand TLS Ticket extension and resumes using the 

Neither of these should happen, because the client can only get
a ticket from a server that supports the extension.

> - the server resumes using the ticket but also sends a sessionID (is this 
As I recall, the suggestion was made not to allow sessionIDs with
tickets so this shouldn't happen.

> handshake and sends a new ticket
This is normal....

> to the client that the server will resume using the ticket?
Isn't that what providing the ticket means?

-Ekr

---

From: Rob Dugal <[email-masked]>
Date: Thu, 6 Oct 2005 09:34:04 -0400

> Isn't that what providing the ticket means?

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.

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?