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

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 29 Sep 2005 12:04:21 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, September 27, 2005 7:01 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt
> 
> Nelson B. Bolyard wrote:
> 
> > 2. I think there needs to be a clear set of rules regarding 
> the use of 
> > SessionIDs with SessionTickets.  Otherwise, clients and servers are 
> > likely to make different assumptions about what is and is not 
> > permissible and be non-interoperable as a result.  I think the 
> > document should answer these questions:
> > 
> > Q1) When the server establishes a new session, and intends 
> to send a 
> > new SessionTicket to the client for subsequent session resumption,
> > 
> > Q1A) Is it permissible to send an empty (zero length) 
> SessionID in the 
> > server_hello, and have the session (in the ticket) still be 
> resumable?
> > 
> > Q1B) Is it permissible for the server to use the same non-empty 
> > SessionID for many different sessions (given that the real session 
> > info is in the ticket, not in a cache)?
> > 
> > Q2) When the client receives a SessionTicket from a server, and 
> > attempts to resume that session in a subsequent handshake with a 
> > SessionTicket extension to the client_hello, must it send in the 
> > client_hello the same SessionID value that it previously 
> received in 
> > the server_hello (even if it was empty)?
> > 
> > Or, does the ticket extension completely override the SessionID?
> > Could the client ignore the received SessionID and instead send a 
> > client_hello with a zero-length SessionID and the ticket extension, 
> > and still rightfully expect that the session would be resumed?
> 
> My proposal would be that SessionID is used as before (this 
> should minimize changes to client implementations). In other words,
> 
> - When a new session is established, and the server intends
>   to send a new SessionTicket, it also sends a non-empty SessionID.
> - When the client attempts to resume a session using a ticket,
>   it also sends the normal (non-empty) SessionID value.
> - If the server does not wish to resume a session, it starts
>   a full handshake (and replies with a different Session ID)
>   as usual
> 

[Joe] In our current implementation we do the following:

- When a new session is established, and the server intends to issue a
new ticket, it sends a non-empty SessionID.
- When the client attempts to resume a session using a ticket, it sends
an empty SessionID value.
- If the server does not wish to resume a session, it starts a full
handshake (and replies with a different Session ID) as usual.

This is almost the same as you indicated, however currently the server
ignores the SessionID value and the client sends an empty Session ID.
This could allow for independent operation of the server side session
caching and client side session caching if the server supports both.

How about:

"When the client wishes to resume the session, it includes a
SessionTicket TLS extension in the SessionTicket extension within
ClientHello message.  The SessionID value will be ignored if the server
resumes a session using a ticket."

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: "Nelson B. Bolyard" <[email-masked]>
Date: Thu, 29 Sep 2005 17:03:43 -0700

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