The DNS-Based scheme to revoke certificates in Transport Layer Security (TLS) Protocol: TLSR
draft-jilongwang-dnsop-tlsr-01
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jilong Wang , Changqing An , 张程远 | ||
| Last updated | 2023-11-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jilongwang-dnsop-tlsr-01
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5280] Cooper, D., "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile", RFC 5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC6698] Hoffman, P., "The DNS-Based Authentication of Named
Entities (DANE) Transport Layer Security (TLS) Protocol:
TLSA", RFC 6698, August 2012,
<https://www.rfc-editor.org/rfc/rfc6698>.
[RFC6960] Santesson, S., "X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP", RFC 6960, June
2013, <https://www.rfc-editor.org/rfc/rfc6960>.
[RFC8122] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 8122, March 2017,
<https://www.rfc-editor.org/rfc/rfc8122>.
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]