Delegated credential
Delegated credential is a short-lived TLS certificate used to improve security by faster recovery from private key leakage, without increasing the latency of the TLS handshake. It is currently an IETF Internet Draft,[1] and has been in use by Cloudflare[2] and Facebook,[3] with browser support by Firefox.[4]
Motivation
Modern websites and other services use content delivery networks (CDNs), which are servers potentially distributed all over the world, in order to respond to a user's request as fast as possible, alongside other services that CDNs provide such as DDoS mitigation. However, in order to establish a secure connection, the server is required to prove possession of a private key associated with a certificate, which serves as a chain of trust linking the public key and a trusted party. The trusted party is normally a certificate authority (CA).
CAs issue these digital certificates with an expiration time, usually a few months up to a year. It is the server's responsibility to renew the certificate close to its expiration date. Knowledge of a private key associated to a valid certificate is devastating for the site's security, as it allows Man-in-the-middle attacks, in which a malicious entity can impersonate to a user as a legitimate server. Therefore, these private keys should be kept secure, preferably not distributed over every server in the CDN. Specifically, if a private key is compromised, the corresponding certificate should optimally be revoked, such that browsers will no longer support this certificate. Certificate revocation has two main drawbacks. Firstly, current revocation methods do not work well across all browsers, and put the users at risk; and secondly, upon revocation, the server needs to quickly fetch a new valid certificate from the CA and deploy it across all mirrors.
Design
A delegated credential is a short-lived key (from a few hours to a few days) that the certificate's owner delegates to the server for use in TLS. It is in fact a signature: the certificate's owner uses the certificate's private key to sign a delegated public key, and an expiration time.
Given this delegated credential, a browser can (if it supports it) verify the server's authenticity by verifying the delegated certificate and then verify the certificate itself.
Advantages
This approach has many advantage over current solutions:
- Delegated credentials are short-lived, so private keys can be changed frequently. Therefore, even if a particular delegated credential is compromised without certificate owner knowing it, that compromised credential could only be abused for a very short time.
- No revocation is needed for stolen certificates.[citation needed]
- The certificate owner does not need to expose its private key to the CDN servers, but rather periodically supply them with delegated credentials. Therefore, certificate owner can maintain exclusive control over its private key (and even store it in HSM) while using third-party CDN servers.
- The delegated credential has its own key, so it can experiment with new algorithms such as Ed25519. This can facilitate cryptographic agililty.
References
- ↑ Barnes, Richard; Iyengar, Subodh; Rescorla, Eric; Sullivan, Nick. "Delegated Credentials for TLS" (in en). https://tools.ietf.org/html/draft-ietf-tls-subcerts. Retrieved 21 June 2020.
- ↑ "Delegated Credentials for TLS" (in en). 1 November 2019. https://blog.cloudflare.com/keyless-delegation/. Retrieved 21 June 2020.
- ↑ Guzman, Alex; Nekritz, Kyle; Iyengar, Subodh (1 November 2019). "Delegated credentials: Improving TLS security". https://engineering.fb.com/security/delegated-credentials/. Retrieved 21 June 2020.
- ↑ Jacobs, Kevin; Jones, J. C.; Merwe, Thyla van der. "Validating Delegated Credentials for TLS in Firefox". https://blog.mozilla.org/security/2019/11/01/validating-delegated-credentials-for-tls-in-firefox/. Retrieved 21 June 2020.
 |  |
