Re: [TLS] Question on Stateless TLS Session Resumption

[Re-sending to the mailing list...]

"Narayanan, Vidya" <vidyan@qualcomm.com> writes:

> All,
> RFC4507 makes no mention of ticket replays at all, which I find to be a
> bit surprising. It actually doesn't talk about message replays either,
> but, since the protocol takes 1.5 RTs,  both parties prove to be live
> and so, that is not a problem. But, ticket replays seem to be of some
> concern. Based on the fact that the ticket contains a timestamp, using
> which expiry can be determined, it appears that a given ticket will be
> accepted until its expiry time, even if a newer ticket may have been
> issued after that.

Right. There's nothing wrong with this.

> This itself is not so much a problem, since, the
> client really has no incentive in using an older ticket as opposed to
> the latest one. However, if a new ticket is either not issued or if the
> session is terminated by the server for some reason, this seems to be a
> problem.

Well, there are two separate issues here. There's no technical
reason why a new TLS handshake between a client/server pair
needs to invalidate and old session between them. Indeed,
I don't know of any server which enforces this before and it
would even in principle be rather difficult to do in the
absence of client authentication, which is fairly rare.

This leaves us with ticket invalidation which does, as you
note, require server side state, though rather less than
that required by an ordinary session cache. 

> Since there is really no means of ticket revocation or any
> server state on the status of a ticket, there seems to be no way to
> determine that the client is not supposed to be using that ticket to
> resume a session. Also, the fact that the client is allowed to pick a
> Session ID makes it infeasible to track a terminated session that must
> not be allowed to resume. 

I don't think I understand this point. Both session IDs and 
tickets are generated by servers.

> Am I missing something? Has this been talked about before? 

Yes, it's discussed extensively in the SBR04 paper on Client-Side
Session Caching.

Shacham, H., Boneh, D., and E. Rescorla, "Client-side
caching for TLS", Transactions on Information and System
Security (TISSEC) , Volume 7, Issue 4, November 2004.

-Ekr

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls