Re: [TLS] Question on Stateless TLS Session Resumption

[Lakshminath Dondeti <[e-mail]>]

Eric Rescorla wrote:

> 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.

The issue is that of revocation.  If a client's credentials are revoked, 
a full exchange will ensure that the client gets service only after it 
acquires/renews its certificate or whatever.  If there is an old ticket 
that the client can use to get service then it  is able to get around 
having to reauthenticate with new credentials.

> 
> 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.

Right, that's as per 4346.  However, 4507 says "When presenting a 
ticket, the client MAY generate and include a Session ID in the TLS 
ClientHello."  Given that the client can change the session id, it 
becomes difficult (not impossible as I initially thought) for the server 
to track and invalidate old tickets.  But, perhaps as you say, this is 
generally not an issue in practice.  If the ticket lifetime is generally 
short enough, it is probably not a big deal (although it would have been 
nice to have stated it in 4507).

regards,
Lakshminath
> 
> 
>> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tls
> 

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