Internet-Draft TLSR November 2023
Wang, et al. Expires 25 May 2024 [Page]
Intended Status:
WJL. Wang, Ed.
Tsinghua University
CQA. An, Ed.
Tsinghua University
ZCY. Zhang, Ed.
Tsinghua University

The DNS-Based scheme to revoke certificates in Transport Layer Security (TLS) Protocol: TLSR


This memo presents the definition of a new DNS resouce record type named TLSR, and then discusses a new framework for certificate revocation and certificate status verification. This document can solve the existing problems in the current certificate revocation schemes. This requires matching improvements in TLS client software, but no change in TLS server software.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 25 May 2024.

Table of Contents

1. Introduction

1.1. Background and Motivation

Digital certificates are the carrier of trust in the Web Public Key Infrastructure (PKI) system. A certificate is supposed to be treated as valid before their expiry date. However, if a certificate has security issues, such as using a compromised private key or an insecure encryption algorithm, it needs to be revoked as soon as possible because the websites using it are vulnerable to phishing and man-in-the-middle attacks.

Certificate Revocation List (CRL) [RFC5280] and Online Certificate Service Protocol (OCSP) [RFC6960] are two methods to check the revocation status of a certificate. However, such methods can be slow and may have privacy issues. CRL and OCSP requires browsers to establish an additional HTTP connection with CAs, which is costly. Sending OCSP queries can leak the user's browsing history to CAs, which may cause privacy issues. Considering these reasons, the two methods are not commonly supported by modern browsers. Therefore, browsers need a fast and privacy-preserved method for checking the revocation status of a certificate.

Another motivation is that the structure of web PKI has become more centralized over time with a small number of CAs issuing a large percentage of total certificates, but CAs are not always reliable and can get attacked and misbehave. If a CA is under attack, websites that use certificates issued by the CA have no choice but to wait for the CA to recover and revoke the fraudulent certificates. This may take as long as a few days, which is sufficient for attackers to launch a successful man-in-the-middle attack. Therefore, we want to provide a way for domain holders to take control of the revocation status of their own ceritificates and reduce the harm brought by compromised CAs.

1.2. New Certificate Revocation Method

This document defines a new DNS resource record type which provides a way for DNS domain name holders to quickly and independently revoke their certificates without the involvement of Certificate Authorities (CA). This document also defines a fast method for TLS clients to verify the status of a certficiate using DNS. Note that the DNS information needs to be protected by DNSSEC, which uses cryptographic keys and digital signatures to authenticate the retrieved DNS data.

This document does not specify how the client validates the DNSSEC data. This document only relates to getting the DNS information for the certificate association securely using DNSSEC; other secure DNS mechanisms are out of scope.

1.3. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. TLSR RR Type

First we define a new type of DNS resource record named TLSR to store the information of revoked certificates. Note that although RFC6698 [RFC6698] has proposed TLSA record to store certificates in DNS resource record, we want to simplify it to reduce the overhead by storing revoked certificates in DNS servers.

A TLSR RR consists of a one-octet selector field and and the certificate association data field.

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |   Selector    |                                               /
   +-+-+-+-+-+-+-+-+         Certificate Association Data          /
   /                                                               /

2.1. The Selector Field

The first one-octet value, called "Selector", specifies which part of the TLS certificate presented by the server will be matched against the association data. This value is defined in a new IANA registry (see Section 8.1). The selectors defined in this document are:

Full certificate: the Certificate binary structure as defined in RFC5280 [RFC5280]

SubjectPublicKeyInfo: DER-encoded binary structure as defined in RFC5280 [RFC5280]

Fingerprint: a secure one-way hash of the DER (distinguished encoding rules) form of the certificate as defined in RFC8122 [RFC8122]

Serial number: DER-encoded binary structure as defined in RFC5280 [RFC5280]

2.2. The Certificate Association Data Field

This field specifies the "certificate association data" to be matched. These bytes are raw data of either the full certificate, its SubjectPublicKeyInfo, its fingerprint or its serial number, depending on the selector.

2.3. TLSR RR Examples

An example of a revoked certificate using the serial number as selector: IN TLSR (
    3 1 034CA550FC5542C320057C7BEA24F5AA56D5)

3. Use of TLSR Records

3.1. Revoke Certificates

Domain owners can use TLSR Records to quickly revoke their certificates without the participation of CAs. When a certificate needs to be revoked, the domain owner can submit the certificate to the DNS provider, and the DNS provider must publish the corresponding TLSR record. A domain can have multiple TLSR records since the domain can have multiple revoked certificates. Note that domain holders SHOULD only use TLSR records to store certificates that need to be revoked, and expired certificates SHOULD NOT be stored with TLSR records.

3.2. Verify the Status of a Certificate

When a TLS client wants to build a HTTPS connection with a website, it SHOULD first query the DNS server to get the TLSR records of this website. The TLS client needs to send a TLSR type DNS query to the DNS server for this domain's TLSR records, and the DNS server is supposed to respond with all the TLSR records of this domain. After receiving the TLSR records, the TLS client SHOULD parse these records and get the identifiers of the domain's revoked certificates. Then when the TLS client receives the website's certificate during the handshake, the browser should compare the identifiers specified by the TLSR records with the corresponding data in the certificate. If the data matches, which indicates that the certificate has been revoked by the domain owner and the connection is no longer secure, then the browser MUST terminate the connection immediately.

4. The Certificate Revocation Scheme

This document describes a new certificate revocation scheme that is an alternative to CRL and OCSP. This scheme can provide more flexibility to the domain name holders and reduce the impact of attacks on CAs. Besides, our scheme also solves the privacy problem brought by querying the OCSP server.

4.1. Participants

The participants and their roles in the certificate revocation process are as follows:

The picture below can describe the interactions between these participants. Suppose a CA issues the domain a certificate C0 and the domain holder wants to revoke the certificate since C0's private key is compromised. The domain holder submits C0 to the DNS server which adds a TLSR record for the domain. When a TLS client wants to connect with a domain using the revoked certificate, the client will find that the certificate is revoked immediately and abort the TLS connection.

  |    CA   |
       | C0
  +---------+        +------------+        +------------+
  | Website |        | DNS Server |        | TLS Client |
  +---------+        +------------+        +------------+
       |                   |<----- A, TLSR-------|
       |                   |----IP, Rev List---->|
       |                   |             DNSSEC Validation
       |                   |                     |
       |<========TLS Handshake Starts===========>|
       |============ServerHello, C0=============>|
       |                   |                     |
       |                   |            Validate(C0, RevList)
       |---------X Connection Abort X------------|

5. Mandatory-to-Implement Features

5.1. TLS Clients

TLS clients conforming to this specification MUST be able to correctly interpret TLSR records with certificate selectors 0, 1, 2, and 3. TLS clients conforming to this specification MUST be able to compare a certificate association with a certificate from the TLS handshake using selector types 2 (fingerprint) and 3 (serial number), and SHOULD be able to make such comparisons with selector 0 (full certificate) and 1 (SubjectPublicKeyInfo).

5.2. DNS Service Providers

The DNS service providers MUST implement the support for TLSR records, including adding new TLSR records to a domain and responding TLSR queries correctly.

6. Security Considerations

The security considerations are similar to that of TLSA records [RFC 6698]. The security of the DNS RRtype described in this document relies on the security of DNSSEC to verify that the TLSR record has not been altered. A rogue DNS administrator who changes the A, AAAA, and/or TLSR records for a domain name can cause the client to go to an unauthorized server that will appear authorized, unless the client performs PKIX certification path validation and rejects the certificate. However, that administrator could probably get a certificate issued by some CA anyway, so this is not an additional threat.

6.1. External DNSSEC Validators

As indicated in RFC6698 [RFC6698], Nothing prevents a compromised external DNSSEC validator from claiming that all the records it provides are secure, even if the data is falsified, unless the client checks the DNSSEC data itself (rendering the external validator unnecessary). For this reason, DNSSEC validation is best performed on-host, even when a secure path to an external validator is available.

6.2. DNS Cache

Similar to the situation in RFC6698 [RFC6698], implementations should rely on their DNS resolver for confirmation of an association between a TLSR record and a DNS name, rather than caching the result of previous domain name lookups. If implementations cache the results of domain name lookups in order to achieve a performance improvement, they MUST observe the TTL information reported by DNS. Implementations that fail to follow this rule could make an urgent certificate revocation become temporarily invisible and extend the attack window.

6.3. Excessive TLSR Records

Since a domain can have multiple TLSR Records and a TLSR record can store a full certificate, an attacker can register a legal domain then submit excessive TLSR Records to a DNS server to crush it. An attacker can also register a domain and submit many TLSR Records to the DNS server, then the attacker can spoof the victim's IP and send too many TLSR queries to the DNS server so that the target receives an amplification of the attacker's initial traffic, causing a denial-of-service.

It is RECOMMENDED that the maximum number of TLSR records that a domain can have is limited, because normally a domain is supposed to not have so many revoked certificates since a certificate SHOULD only be revoked under urgent situations like compromised private key. It is also RECOMMENDED to limit the maximum size of one TLSR record. These limitations can increase the difficulty of launching such an amplification attack.

7. IANA Considerations

This document uses a new DNS RR type, TLSR, whose value is still to be determined by IANA.

This document also creates a new registry, "TLSR Selectors", and the initial entries in the registry are:

    Value       Short description              Reference
    TBD1        Full certificate          this RFC, section 2.1
    TBD2        SubjectPublicKeyInfo      this RFC, section 2.1
    TBD3        Fingerprint               this RFC, section 2.1
    TBD4        Serial number             this RFC, section 2.1

8. Acknowledgements

The authors would like to thank the support of Tsinghua. University. We also thank the following persons for their suggestions on earlier versions of this work, etc, for their. discussion, comments and suggestions.

9. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, , <>.
Cooper, D., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, , <>.
Hoffman, P., "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, , <>.
Santesson, S., "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, , <>.
Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, , <>.

Appendix A. Practical Considerations

A.1. The choice of selector

There are 4 types of data that can be used as unique identifiers for certificates: full certificate, SHA-256 fingerprint, public key and serial number. Although TLSA record supports storing a full certificate or a public key, the size of a full certificate or a public key (typically 2048bits) is still too large. The size of a SHA-256 fingerprint is 32 bytes and each certificate should have a unique one. As for serial numbers, we examine about 2.5 million serial numbers in our downloaded CRLs, and we find that the size of the largest serial number is 20 bytes, and the average size is 17 bytes, which can represent 2^136 different serial numbers. Although the serial number is only guaranteed to be unique under the same CA, we consider the probability of such a collision to be very low, and using the serial number can reduce the amount of bytes transferred. Therefore, we believe that the serial number is the best choice for the certificate's identifier.

A.2. Parallelize the DNS queries

The TLS client can query the domain's IP and certificate revocation list in parallel. This means that the client does not have to do the DNS query AFTER it receives the certificate. Instead, the client can get the revocation list BEFORE receiving the certificate. Therefore, the time overhead brought by our scheme can be minimized.

We implemented a DNS server that supports TLSR record by modifying BIND9. We also used JavaScript to implement a client that can simulate a TLS client to execute our revocation checking scheme. First we let the client query the DNS server for both the IP address and the list of revoked certificates in parallel, then the client validate the DNS responses using DNSSEC and resolve them. In our experimental environment, the client takes 15-25ms to get the IP of a domain name and 30-40ms to establish a TCP connection with the IP address and send ClientHello. We see that querying a list of revoked certificates adds only 5-10 milliseconds of overhead, and the parsing and validating process can always be completed before the TLS handshake starts.

Appendix B. Pseudocode

This appendix describes, in pseudocode format, the procedure of a TLS client using a domain's TLSR record to check the revocation status of the certificate received during TLS handshake. If the code below contradict the text earlier in this document, the text earlier in this document should be considered correct and the code incorrect.

  function Finish(F) = {
    if (F == ABORT){
      abort the TLS handshake
    if (F == NO_TLSR){
      fall back to other certificate revocation checking schemes
    if (F == PASS){
      certificate revocation checking passes
    // unreachable

  function Select (S, C) = {
    if (S == Full Certificate) {
      return C in DER encoding
    if (S == SubjectPublicKeyInfo) {
      return C.SubjectPublicKeyInfo in DER encoding
    if (S == Fingerprint) {
      return C.Fingerprint in DER encoding
    if (S == Serial Number) {
      return C.Serial Number in DER encoding
    // unreachable

  (TLSRrecords, ValState) = DNSSECValidatedLookup(
    domainname=domainname, RRtype=TLSR)
  LeafCertificate = ParseFrom(ServerHello)
  if (ValState == BOGUS){
  if ((ValState == INDETERMINATE) or (ValState == INSECURE)) {
  for each record in TLSRrecords {
    if record is unusable {
      remove this record from TLSRrecords
  if length(TLSRrecords) == 0 {

  for each R in TLSRrecords {
    if Select(R.Selector, LeafCertificate) ==
      R.CertificateAssociationData {

Authors' Addresses

Jilong Wang (editor)
Tsinghua University
Changqing An (editor)
Tsinghua University
Chengyuan Zhang (editor)
Tsinghua University