Delegated Credentials for TLS, is the technical specifications for new cryptographic protocol announced by Mozilla, in conjunction with Cloudflare, Facebook, and some other members of IETF community.

The new cryptographic protocol will prevent the misuse of stolen certificates by the reduction on maximum validity period of such certificate to a short period of time, like days or even hours, instead of several years. It is a rather simplified way to make certificates "short-lived" without necessarily sacrificing the reliability of the secure connections.

While HTTPS-protected website provides its TLS certificate to the web browser for confirmation of identity before the actual exchange of information, including passwords and other sensitive data, such certificates are expected to last for the entire validity period, but some certificate can go bad before its expiration date for different reasons.

And the main reason a certificate can go bad before expiration, is when the secret private key corresponding to the certificate has been stolen, or the certificate was issued fraudulently, allowing attackers to impersonate the targeted server or spy on encrypted connections via man-in-the-middle attack.

There are over 70% of websites on the Internet currently using TLS certificates to establish secure route of HTTPS communication between the servers and visitors, which ensures the privacy and integrity of data being exchanged, so obtaining TLS certificate from any Certificate Authority (CA) need to be trusted by all major browsers.

Now, the major tech companies like Google, Facebook, and Cloudflare do offer services from several different servers scattered all over the world, and distribute private certificate keys to every one of the servers, which process increases the risk of compromise.

The compromise of certificate before its expiration date, allows only one option for the website operator, that is to request for the certificate authority to revoke the certificate and reissue new one in its place with a different private key.

But the revocation mechanisms are equally broken in practice, because the browsers should normally be able to promptly detect none-trusted certificates so as to proactively prevent users from getting connected to a compromised server, until it gets a new valid certificate.

So modern browsers either use cached validation of a certificate for awhile or assume it is still valid in cases the browser did not receive a valid response from the CA or encounter connection error. In order to further reduce this time frame, most web companies have already started experimenting on certificates with shorter validation period, after which the browser will reject them instead of waiting for revocation signal.

The problem with this experiments is that the CA is separate organization, which a website server would need to fetch new certificates from more frequently, and there's no reliable way for the companies to continuously rotate certificates after every hours or few days.

The IETF community members sort to tackle the issue by proposing for the Delegated Credentials for TLS, as a new cryptographic protocol that will balance the trade-off processes. So now, instead of the deployment of the actual private key to all servers by the CA, the companies can now generate it internally, and deploy as delegated credentials.

How the Delegated Credentials For TLS will boost TLS Protocol Security



Delegated Credentials for TLS, is the technical specifications for new cryptographic protocol announced by Mozilla, in conjunction with Cloudflare, Facebook, and some other members of IETF community.

The new cryptographic protocol will prevent the misuse of stolen certificates by the reduction on maximum validity period of such certificate to a short period of time, like days or even hours, instead of several years. It is a rather simplified way to make certificates "short-lived" without necessarily sacrificing the reliability of the secure connections.

While HTTPS-protected website provides its TLS certificate to the web browser for confirmation of identity before the actual exchange of information, including passwords and other sensitive data, such certificates are expected to last for the entire validity period, but some certificate can go bad before its expiration date for different reasons.

And the main reason a certificate can go bad before expiration, is when the secret private key corresponding to the certificate has been stolen, or the certificate was issued fraudulently, allowing attackers to impersonate the targeted server or spy on encrypted connections via man-in-the-middle attack.

There are over 70% of websites on the Internet currently using TLS certificates to establish secure route of HTTPS communication between the servers and visitors, which ensures the privacy and integrity of data being exchanged, so obtaining TLS certificate from any Certificate Authority (CA) need to be trusted by all major browsers.

Now, the major tech companies like Google, Facebook, and Cloudflare do offer services from several different servers scattered all over the world, and distribute private certificate keys to every one of the servers, which process increases the risk of compromise.

The compromise of certificate before its expiration date, allows only one option for the website operator, that is to request for the certificate authority to revoke the certificate and reissue new one in its place with a different private key.

But the revocation mechanisms are equally broken in practice, because the browsers should normally be able to promptly detect none-trusted certificates so as to proactively prevent users from getting connected to a compromised server, until it gets a new valid certificate.

So modern browsers either use cached validation of a certificate for awhile or assume it is still valid in cases the browser did not receive a valid response from the CA or encounter connection error. In order to further reduce this time frame, most web companies have already started experimenting on certificates with shorter validation period, after which the browser will reject them instead of waiting for revocation signal.

The problem with this experiments is that the CA is separate organization, which a website server would need to fetch new certificates from more frequently, and there's no reliable way for the companies to continuously rotate certificates after every hours or few days.

The IETF community members sort to tackle the issue by proposing for the Delegated Credentials for TLS, as a new cryptographic protocol that will balance the trade-off processes. So now, instead of the deployment of the actual private key to all servers by the CA, the companies can now generate it internally, and deploy as delegated credentials.

No comments