| Internet-Draft | dnssec-ext-pkix | March 2023 |
| Lee & Kwon | Expires 8 September 2023 | [Page] |
The Domain Name System Security Extensions (DNSSEC) were standardized a couple of decades ago but it has not been widely deployed. Thus, a vast majority of DNS messages in the real world are still vulnerable to various kinds of integrity attacks like cache poisoning attacks. This document describes a mechanism that extends the current DNSSEC protocol in such a way that guarantees the integrity of DNS messages using PKIX certificates without any dependencies on other entities in the DNS infrastructure.¶
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 8 September 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
The DNSSEC [RFC4033] was standardized to provide integrity and authentication of DNS records. After twenty years of its introduction, DNSSEC is widely deployed for top-level domains. However, its deployment rates in second-level domains are low and most DNS messages in the real world are still vulnerable to tampering like cache poisoning attacks.¶
In addition, to support DNSSEC, it is necessary that a domain publishes DS records to its upper zone (i.e., parent zone) to establish a chain of trust. Usually, this process requires manual intervention of domain owners which often results in errors. Thus, it is reported that a large number of domains do not have their corresponding DS records in their upper zones [DNSSEC-Deployment], which results in DNSSEC validation failures. Thus, we need a more practical and deployable mechanism to guarantee the integrity and authenticity of DNS records.¶
This document specifies DNSSEC-PKI to provide the integrity and authentication of DNS Resource Record sets (RRsets) by leveraging PKIX [RFC5280] certificates. DNSSEC-PKI offers domain owners another option to provide the DNS integrity without requiring the cooperation (or dependencies) of other entities in the DNS infrastructure (e.g., establishing a chain of trust across zones). For this purpose, DNSSEC-PKI exploits PKIX certificates widely used by most domains. Thus, DNSSEC-PKI allows a domain (or a zone) to use a public/private key pair from its certificate rather than generating a distinct key for DNS. This document defines the requirements and operations of domains and validators (e.g., resolvers) to support DNSSEC-PKI.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
DNSSEC-PKI is designed to provide a practical and deployable way that guarantees the integrity and authenticity of DNSSEC RRsets. To achieve this, we need a mechanism that does not have dependencies on other entities in the DNS infrastructure.¶
We consider two requirements when designing DNSSEC-PKI.¶
Minimum or no changes of other entities in the DNS infrastructure:¶
Maximum reuse of the current DNSSEC standards and DNS infrastructure:¶
+---------------+
| Certificate |
| Authority |
| (CA) |
+---------------+
|
| Certificate
v
+----------+ +---------------+
| | RRSIG, DNSKEY, CERT | |
| Client |<--------------------------| Authoritative |
| | | Name Server |
| | | |
+----------+ +---------------+
To satisfy the design requirements, we leverage PKIX certificates issued by CAs. A domain generates a private/public key pair. Also, it asks a CA to issue a certificate that contains its domain name and the public key. It then uses the private key to generate the signatures of its DNS RRsets. Each signature (for each RRset) is published as a DNS record. Here, we reuse an RRSIG record [RFC4034], which is used to store the signature of an RRset. The domain publishes the public key in the certificate as a DNSKEY record [RFC4034]. Also the certificates in the certificate chain are published as CERT records [RFC4398]. The signature (i.e., RRSIG record) guarantees the integrity and authenticity of the corresponding DNS RRset and the certificate guarantees that the signature is generated by the domain owner’s private key.¶
A validator (e.g., a client or a resolver) can check the integrity of a given RRset by fetching the corresponding signature (RRSIG), a public key (DNSKEY), and a certificate chain (CERTs) and verifying them.¶
Validator Authoritative Certificate
(e.g., Resolver) Name Server Authority
| | (CA)
| | Issue a certificate |
| |<---------------------------|
| | |
| |
| |
| + Generate signatures of RRsets
| |
| + Publish RRSIG, DNSKEY, CERT records
| |
| Fetch a target DNS record |
| (i.e., A record) |
|<-----------------------------|
| |
| Fetch RRSIG, DNSKEY, CERT |
|<-----------------------------|
| |
| |
+ Verify the target record |
| using RRSIG, DNSKEY, CERT |
| |
Deploying DNSSEC-PKI on the authoritative DNS server (i.e., a domain or a zone) requires the following steps:¶
For each RRset, the domain generates its signature and publishes it as an RRSIG record.¶
ost domains use PKIX [RFC5280] certificates for HTTPS (or TLS). Thus, they are familiar with how to handle such certificates (issuance, storage, and so on). We also rely on PKIX certificates issued by CAs for DNSSEC-PKI.¶
We use RRSIG records for digital signatures of RRsets, which are generated by a private key in a PKIX certificate. The description of the RRSIG RR format is specified in Section 3 of [RFC4034]. The Key Tag field should be calculated as explained in Appendix B of [RFC4034].¶
A validator can fetch and validate RRSIG records to check the integrity and authenticity of DNS RRs.¶
Like DNSSEC, DNSSEC-PKI uses the public key cryptography to generate signatures of DNS RRsets. Thus, a domain should publish the public key as a DNS record. Also, the domain should publish a certificate that contains the public key and its certificate chain to allow a DNS client to validate the certificate and the signature. For this purpose, we use two existing DNS resource record (RR) types in DNSSEC.¶
A domain (or zone) generates the signatures of DNS RRsets using its private key. The corresponding public key is stored in a DNSKEY RR which is described in Section 2 of [RFC4034]. As specified in Section 2 of [RFC4034], a DNSKEY RR MUST have a signature algorithm and a public key.¶
Other fields except the Flags field have the same meaning as those specified in Section 2 of [RFC4034].¶
[RFC4034] specifies the use of two bits in the Flags field. Bit 7 is used to specify the Zone Key flag. If bit 7 is set to 1, the DNSKEY RR contains a DNS zone key. Otherwise, the DNSKEY MUST NOT be used to verify RRSIGs. Thus, to use DNSSEC-PKI, bit 7 MUST be set to 1.¶
Bit 15 is used to specify the Secure Entry Point flag which is described in [RFC3757]. If bit 7 is set to 1, the DNSKEY RR contains a key-signing key (KSK). Otherwise, the DNSKEY RR contains a zone-signing key (ZSK). In DNSSEC-PKI, a private key corresponding to the public key in the DNSKEY RR is used to sign a zone’s RRsets, and hence its role is similar to that of a ZSK. Thus, for DNSSEC-PKI, bit 7 MUST be set to 0.¶
We propose to use bit 3 to specify whether the DNSSEC-PKI extension is supported flag (P). If bit 3 is set to 1, the public key in DNSKEY RR MUST be validated using the certificates in CERT RRs (specified in Section 3.2.2).¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |P| flags | protocol | algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A CERT RR [RFC4398] contains a PKIX certificate. The certificate includes a public key which is also included in a DNSKEY RR.¶
A Key Tag should be calculated using the public key in the certificate as specified in Appendix B of [RFC4034].¶
We assume that a DNS client already stores the certificate of a root CA. Thus, CERT RRs include the certificates of the domain, issuing CA and intermediate CAs (excluding the root CA).¶
DNSSEC-PKI guarantees the integrity and authenticity of DNS RRs based on public key cryptography. Validators should verify the signatures of DNS RRsets generated by domains.¶
To check the integrity and authenticity of DNS RRs, a validator:¶
The signature verification will result in one of the following:¶
If a client trusts a (local or public) resolver, the resolver should validate the signature of DNS RRs and return the result to the client. A resolver sets the Authenticated Data (AD) bit in the message header of the DNS response message if and only if the queried RRset is authenticated.¶
If a client does not trust the resolver, it should verify the signature (RRSIG) by itself.¶
We ask to update the “DNSKEY FLAGS” registry [RFC3755][RFC4034] to assign 3rd bit in the DNSKEY Flags as the DNSSEC-PKI (P) bit.¶
| Number | Description | Reference |
|---|---|---|
| 3 | DNSSEC-PKI (P) | Section 3.2.1.1 of this document |
We recommend using the NSEC [RFC4034] or NSEC3 [RFC5155] mechanism to provide the authenticated denial of existence.¶
DNSSEC-PKI leverages PKIX certificates issued by CAs. However, Certificate Authorities (CAs) have been criticized since there are no limits in a namespace in terms of certificate issuance. Protocols such as DNS CAA [RFC8659] and Certificates Transparency [RFC9162] can mitigate the problem.¶