dnsop WJL. Wang, Ed. Internet-Draft CQA. An, Ed. Intended status: Informational ZCY. Zhang, Ed. Expires: 25 May 2024 Tsinghua University 22 November 2023 The DNS-Based scheme to revoke certificates in Transport Layer Security (TLS) Protocol: TLSR draft-jilongwang-dnsop-tlsr-01 Abstract 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 https://datatracker.ietf.org/drafts/current/. 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. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Wang, et al. Expires 25 May 2024 [Page 1] Internet-Draft TLSR November 2023 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Background and Motivation . . . . . . . . . . . . . . . . 3 1.2. New Certificate Revocation Method . . . . . . . . . . . . 3 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. TLSR RR Type . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. The Selector Field . . . . . . . . . . . . . . . . . . . 4 2.2. The Certificate Association Data Field . . . . . . . . . 5 2.3. TLSR RR Examples . . . . . . . . . . . . . . . . . . . . 5 3. Use of TLSR Records . . . . . . . . . . . . . . . . . . . . . 5 3.1. Revoke Certificates . . . . . . . . . . . . . . . . . . . 5 3.2. Verify the Status of a Certificate . . . . . . . . . . . 5 4. The Certificate Revocation Scheme . . . . . . . . . . . . . . 6 4.1. Participants . . . . . . . . . . . . . . . . . . . . . . 6 5. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 7 5.1. TLS Clients . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. DNS Service Providers . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6.1. External DNSSEC Validators . . . . . . . . . . . . . . . 8 6.2. DNS Cache . . . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Excessive TLSR Records . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Practical Considerations . . . . . . . . . . . . . . 9 A.1. The choice of selector . . . . . . . . . . . . . . . . . 10 A.2. Parallelize the DNS queries . . . . . . . . . . . . . . . 10 Appendix B. Pseudocode . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Wang, et al. Expires 25 May 2024 [Page 2] Internet-Draft TLSR November 2023 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. Wang, et al. Expires 25 May 2024 [Page 3] Internet-Draft TLSR November 2023 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] Wang, et al. Expires 25 May 2024 [Page 4] Internet-Draft TLSR November 2023 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: www.example.com 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. Wang, et al. Expires 25 May 2024 [Page 5] Internet-Draft TLSR November 2023 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: * CA: CA can issue certificates to domain owners. * DNS Server: DNS servers use TLSR records to store the association between domains and their revoked certificates. * TLS Client: TLS Clients can send TLSR requests to the DNS server to get the domain's list of revoked certificates. The browser SHOULD verify that the certificate received during the TLS handshake is not in the list, otherwise the connection SHOULD be terminated immediately. Note that TLS clients can use this list to check the status of leaf certificates, and TLS clients can use mechanisms like OneCRL for checking the revocation status of intermediate certificates and root certificates. * Domain Holder: Domain holders can send request with the certificate to be revoked to the DNS server. DNS server SHOULD build a new TLSR resource record according to the request and add it to the domain's DNS resource records. 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. Wang, et al. Expires 25 May 2024 [Page 6] Internet-Draft TLSR November 2023 +---------+ | CA | +---------+ | C0 V +---------+ +------------+ +------------+ | 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 Wang, et al. Expires 25 May 2024 [Page 7] Internet-Draft TLSR November 2023 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. Wang, et al. Expires 25 May 2024 [Page 8] Internet-Draft TLSR November 2023 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . [RFC5280] Cooper, D., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008, . [RFC6698] Hoffman, P., "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012, . [RFC6960] Santesson, S., "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013, . [RFC8122] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, March 2017, . Appendix A. Practical Considerations Wang, et al. Expires 25 May 2024 [Page 9] Internet-Draft TLSR November 2023 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. Wang, et al. Expires 25 May 2024 [Page 10] Internet-Draft TLSR November 2023 function Finish(F) = { if (F == ABORT){ abort the TLS handshake exit } if (F == NO_TLSR){ fall back to other certificate revocation checking schemes exit } if (F == PASS){ certificate revocation checking passes exit } // 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){ Finish(ABORT) } if ((ValState == INDETERMINATE) or (ValState == INSECURE)) { Finish(NO_TLSR) } for each record in TLSRrecords { if record is unusable { remove this record from TLSRrecords } } if length(TLSRrecords) == 0 { Finish(NO_TLSR) Wang, et al. Expires 25 May 2024 [Page 11] Internet-Draft TLSR November 2023 } for each R in TLSRrecords { if Select(R.Selector, LeafCertificate) == R.CertificateAssociationData { Finish(Abort) } } Finish(PASS) Authors' Addresses Jilong Wang (editor) Tsinghua University Beijing 100084 China Email: wjl@tsinghua.edu.cn Changqing An (editor) Tsinghua University Beijing 100084 China Email: acq@tsinghua.edu.cn Chengyuan Zhang (editor) Tsinghua University Beijing 100084 China Email: chengyua21@mails.tsinghua.edu.cn Wang, et al. Expires 25 May 2024 [Page 12]