Re: [TLS] Unifying tickets and sessions

[Richard Fussenegger <[e-mail]>]

On 10/23/2014 10:01 PM, Viktor Dukhovni wrote:
> On Thu, Oct 23, 2014 at 03:35:59PM -0400, Stephen Checkoway wrote:
>
>> On Oct 23, 2014, at 2:36 PM, Viktor Dukhovni <[e-mail]> wrote:
>>
>>> The number of key sets is irrelevant, all that matters is how long
>>> each one is retained.  Postfix defaults to 2 hours (1 hour encrypt
>>> and 1 hour decrypt).  With N keysets, you'd have (T encrypt, (N-1)*T
>>> decrypt).
>> This seems perfectly reasonable (both for general N and for
>> specific N = 2 or N = 3). But does it make any difference from a
>> protocol perspective? The only way a client could tell if a server
>> is doing something wrong is if the client knows the upper limit on
>> the ticket's validity  NT and sends a ticket after that time which
>> the server accepts.
> OpenSSL at least enforces the N*T time-limit on sessions, and in
> case would not be able to decrypt a session ticket whose key has
> been discarded.  So Postfix sets 2*T as the session lifetime, and
> as a result if a session ticket is decrypted the session will not
> be accepted.

With N = 2 your tickets are either T or 2 * T, depending on the time the 
client received the ticket. The client sends the ticket to the server 
expecting to continue were it left of but instead ends up with a full 
new handshake because the ticket is rejected, although the lifetime 
indicates that it's valid. (Of course no big deal.)

With N = 3 your ticket is always 2 * T, no matter when the client 
received the ticket. I tried to illustrate that in my simple drawing[1] 
and its the reasoning behind 3 key sets.

That's also were I see the difference for the protocol because all 
clients are treated equally in terms of ticket lifetime and can trust 
that they aren't storing garbage tickets (assuming it was configured 
correctly, but that could be handled by the library).

Richard

[1] http://pastebin.com/1iAatbWm