[openssl.org #4108] Set TLS ticket keys API

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[openssl.org #4108] Set TLS ticket keys API

Rich Salz via RT
Pull request on github: https://github.com/openssl/openssl/pull/452

The existing API for managing RFC 5077 TLS ticket keys is cumbersome:
callers must either specify a key once at startup or they must implement a
complicated callback API.

This new API allows a caller to set a list of TLS ticket keys. The first
key in the list is preferred, and any other keys in the list will be
accepted with an upgrade to a ticket with the preferred key. This scheme
allows groups of servers to implement seamless key rotation strategies.

The original patch comes from Twitter's https://github.com/twitter/sslconfig


_______________________________________________
openssl-bugs-mod mailing list
[hidden email]
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4108] Set TLS ticket keys API

Viktor Dukhovni
On Tue, Oct 27, 2015 at 03:13:27AM +0000, Chris Conroy via RT wrote:

> Pull request on github: https://github.com/openssl/openssl/pull/452
>
> The existing API for managing RFC 5077 TLS ticket keys is cumbersome:
> callers must either specify a key once at startup or they must implement a
> complicated callback API.
>
> This new API allows a caller to set a list of TLS ticket keys. The first
> key in the list is preferred, and any other keys in the list will be
> accepted with an upgrade to a ticket with the preferred key. This scheme
> allows groups of servers to implement seamless key rotation strategies.
>
> The original patch comes from Twitter's https://github.com/twitter/sslconfig

Having written functionally similar code for Postfix some years
back, I should probably review this one.

A few quick comments:

    * The encryption algorithm for session tickets is hardcoded to
      aes-128-cbc.  It should default to aes-256-cbc, and should
      be configurable.

    * I don't see any attempt to synchronize the key rotation cycle,
      with the session lifetime.  If the session cache lifetime is
      shorter than the key lifetime, sessions will be refused as
      stale.

    * In the Postfix implementation, keys have a explicit end-time
      for use in creating new sessions, and another end time for
      use in decrypting existing sessions, and the session lifetime
      is set to exceed the latter.  Instead of applications having
      to provide a list of keys up front, the callback fetches new
      keys as keys expire or session tickets arrive with a key that
      is not available in memory.  This allows applications to
      generate new keys on demand, or fetch them "just-in-time",
      ... which is perhaps more flexible than preloading a list.

I've not yet read all the code in detail, so I might retract some
of the above, but I'd like to ask who'll be the primary contact to
discuss any feedback on the proposed design?  Perhaps we can do
something that takes the best ideas from both the Twitter and the
Postfix approaches (and any others that might have good ideas).

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev