1673254 - RFE: API interfaces to permit setting session ticket encryption keys (STEK)

Status: NEW

(NSS :: Libraries, enhancement, P4)

Description

[gstrauss]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

NSS libraries do not provide public interfaces to set custom session ticket encryption keys (STEK).

(In NSS, I have also seen the STEK referred to as "STE key")

Across multiple servers, it is desirable to share the same STEK so that a session ticket sent by a client can be validated by any server in the server farm to which the client's connection is directed.

Managing a STEK across multiple servers also requires the ability to rotate the STEK keys according to admin policy.

Actual results:

ssl_GetSelfEncryptKeysInt() symbol is not exported in the NSS libraries, and the function declaration is not in headers. Also, sslSelfEncryptKeys is in a private header (lib/ssl/sslimpl.h:struct sslSelfEncryptKeysStr)

Expected results:

Were the above made public (or a better interface which obtained appropriate locks, if needed, during modification), then I would be able to manage the STEK across multiple servers.

The lighttpd web server (beginning with lighttpd 1.4.56) rotates the STEK and provides an option for the admin to manage the STEK externally. lighttpd is able to do so with openssl (and boringssl, libressl, wolfssl using openssl API), mbedTLS, GnuTLS.

However, lighttpd is unable to do so with NSS due to limitations in the NSS API.

(Pointers are appreciated if I overlooked an API in the NSS code.)

Comment 1

[gstrauss]

Perhaps related ticket filed 13 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=421389

Comment 2

[Martin Thomson [:mt:]]

The way that we currently operate is to tie the session key encryption to the server public key. Which only works if you have an RSA key configured. You have to configure a certificate with an RSA key, but you can configure the server to only use EC keys, if that suits you (use SSL_SignatureSchemePrefSet and exclude all of the RSA options and that should work).

I've long said that this is a terrible situation, but it has certain merits in that it doesn't need any special STEK coordination infrastructure, you just use the same infrastructure you use for the distribution of keys. Of course, if you wanted to give instances their own keys, it all breaks down. And then it doesn't deal with EC very well either.

There are likely open issues on providing an interface to setting the self-encryption keys as a symmetric key. I don't remember whether those exist or not and couldn't find them. Another option we might consider is HPKE, which is in the latest NSS release, and configure an asymmetric key instead.

Do you expect symmetric keys or asymmetric keys? Have you any preferences on how keys are identified?

Comment 3

[gstrauss]

Thank you very much for the detailed response.

Do you expect symmetric keys or asymmetric keys?

Random data that is rotated multiple times a day

Have you any preferences on how keys are identified?

No preference. The keyid is random data, too.

My session ticket encryption keys are (cryptographically) random data, and are rotated multiple times a day.
You can see the sample shell script one-liner at https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL#Session-Tickets
It creates random data in a binary structure that includes activation and expiration times.

Rotating the session ticket encryption key multiple times a day increases the security posture for perfect forward secrecy. In contrast, I am prohibited from regenerating certificates quite so frequently from public CAs, e.g. Let's Encrypt.

Also, in some TLS libraries (openssl, mbedtls, wolfssl), I can keep a (short) history of overlapping STEKs as I rotate them so that most recent session tickets can be validated and sessions resumed, while renewing recently-expired session tickets. (I have not evaluated TLS libraries for how complex it would be to manage multiple server certificates for the same server identity, with different, overlapping periods of validity.)

If all of the session ticket encryption keys need to be expired, I can do so nearly instantly, at the cost of invalidating resumption requests for a short period of time afterwards, causing an extra round-trip upon connection establishment. Expiring these session ticket encryption keys is independent of the server identity (the certificate).

I hope that I have explained some benefits of keeping the STEK separate from the server certificate.

The way that NSS ties the STEK to the server public key is an interesting alternative -- not without its own tradeoffs -- to solve the problem of STEK distribution across a server farm.

Thus far, these are the only generic mechanisms I have heard about for session ticket encryption key distribution, besides custom solutions referenced in blogs by CDN providers.

Comment 4

[Benjamin Beurdouche [:beurdouche]]

Martin, could you please set priority and severity for this as you have discussed this issue? Thanks :)