Re: [TLS] Unifying tickets and sessions

[Richard Fussenegger <[e-mail]>]

On 10/23/2014 7:45 PM, Viktor Dukhovni wrote:
> There are only ever two keys sets in memory: the current encryption
> key set and prior encryption (additional decryption) keyset.  I
> say key set because we need an encryption key and an HMAC key and
> both are rotated together, with these is associated a 16 octent id
> (could be a counter or simply random).

I like the wording 'key set' and it's actually what I was referring to 
too. The key sets that are generated in my script for nginx are simply 
48 B of random data (key_name, iv, key, mac):

https://github.com/Fleshgrinder/nginx-session-ticket-key-rotation/blob/master/config.sh#L420-L457
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key

> Actually two key sets are sufficient.  There is no need for a third
> key set.  Take a look at postfix/src/tls/tls_scache.c the relevant
> functions are tls_scache_key() and tls_scache_key_rotate().
>
> This is used in postfix/src/tls/tls_mgr.c tls_mgr_key().
>
>      https://github.com/vdukhovni/postfix

I adopted the three key idea from Twitter[1] and yes two key sets are 
sufficient. I thought that Twitters rational behind the three keys was 
to extend the lifetime of tickets on the client side (as in my drawing 
http://pastebin.com/1iAatbWm) without extending the lifetime of the 
encryption key. Of course I could be terribly wrong here but Jacob 
Hoffman-Andrews for sure had some idea behind this rational.

If the upper limit is said to be two tickets, Twitter has to adopt there 
system. Since we already have a prominent example that uses three 
tickets, its imho a good idea to let them continue doing so. Note that 
your approach would still be perfectly valid because you're below the 
hard limit of three tickets. Hence if one decides to use a single key 
and simply send it to nirvana after 24h then that's okay as well. The 
goal is that we don't botch PFS and not to dictate how keys are implemented.

That said, I have no problem with two keys especially if there is an 
argument against using three keys in regards to security. Maybe I should 
ask Jacob Hoffman-Andrews from Twitter why they are using three keys?

Richard

[1] https://blog.twitter.com/2013/forward-secrecy-at-twitter