Delegation of TLS Authentication to CDNs using Revocable Delegated Credentials
When using a Content Delivery Network (CDN), domain owners typically delegate Transport Layer Security (TLS) authentication to the CDN by sharing their TLS certificate’s private key. However, this practice not only delegates TLS authentication but also grants the CDN complete control over the certificate. To mitigate these concerns, Delegated Credential (DC) was proposed as a solution; DC, which contains both the CDN’s public key and the domain owner’s signature, allows the domain owners to delegate their own credentials for TLS authentication, thereby avoiding the need to share their private keys. However, the absence of a mechanism to distribute the revocation status of a DC renders it non-revocable, even when a compromise of a credential has been detected. DCs were thus designed to be short-lived, necessitating frequent renewal for continued use.
To overcome this limitation, we designed Revocable Delegated Credential (RDC), which provides a revocation method for DCs. With RDCs, there is no need for frequent renewals as they can be revoked, allowing for a longer validity period. The revocation status of RDCs is distributed via DNS, an essential component of web communication. RDCs utilize the NSEC record, a type of DNSSEC record, as a means to store, validate, and easily manage their revocation status. When domain owners no longer trust their CDNs or detect compromise in their RDCs, they can distribute the RDC’s revocation status by simply creating a subdomain named with an RDC identifier. The browser then confirms the existence of this subdomain using the NSEC record to validate the revocation status. We implemented RDC in the go tls package and Firefox Nightly to demonstrate and evaluate its feasibility.