]> Tsinghua University

Beijing 100084 China wjl@tsinghua.edu.cn

Tsinghua University

Beijing 100084 China acq@tsinghua.edu.cn

Tsinghua University

Beijing 100084 China chengyua21@mails.tsinghua.edu.cn

Management dnsop Internet-Draft 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.

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) and Online Certificate Service Protocol (OCSP) 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.

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.

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.

First we define a new type of DNS resource record named TLSR to store the information of revoked certificates. Note that although 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 / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 SubjectPublicKeyInfo: DER-encoded binary structure as defined in RFC5280 Fingerprint: a secure one-way hash of the DER (distinguished encoding rules) form of the certificate as defined in RFC8122 Serial number: DER-encoded binary structure as defined in RFC5280

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.

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

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.

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.

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.

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. +---------+ | 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------------|

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).

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

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.

As indicated in 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.

Similar to the situation in 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.

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.

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

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.

Harvard University VPN Consortium NIST Vidyo 3xA Security

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.

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.

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 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) } for each R in TLSRrecords { if Select(R.Selector, LeafCertificate) == R.CertificateAssociationData { Finish(Abort) } } Finish(PASS)