Internet DRAFT - draft-zhang-ct-dnssec-trans
draft-zhang-ct-dnssec-trans
Network Working Group D. Zhang
Internet-Draft Huawei
Intended status: Experimental July 22, 2014
Expires: January 23, 2015
Certificate Transparency for Domain Name System Security Extensions
draft-zhang-ct-dnssec-trans-00
Abstract
In draft-ietf-trans-rfc6962-bis, a solution is proposed for publicly
logging the existence of Transport Layer Security (TLS) certificates
using Merkle Hash Trees. This document tries to use this idea in
DNSSEC and publicly logging the existence of keys used in securing
DNS resource records.
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].
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 http://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 January 23, 2015.
Copyright Notice
Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of
Zhang Expires January 23, 2015 [Page 1]
Internet-Draft CT-DNSSEC July 2014
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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Cryptographic Components of Certificate Transparency . . . . 3
3. Log Format and Operation . . . . . . . . . . . . . . . . . . 3
3.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 3
4. Including the Signed Certificate Timestamp into DNS Security
Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. SCT RR . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. The Key Tag Field . . . . . . . . . . . . . . . . . . 4
4.1.2. The Algorithm Field . . . . . . . . . . . . . . . . . 5
4.1.3. The Digest Type Field . . . . . . . . . . . . . . . . 5
4.1.4. The Digest Field . . . . . . . . . . . . . . . . . . 5
4.1.5. The SCT Field . . . . . . . . . . . . . . . . . . . . 5
4.2. Operations . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6.1. Logging other types of RRs . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
[I-D.ietf-trans-rfc6962-bis] specifies a Certificate Transparency
(CT) mechanism to disclosing TLS certificates into public logs so as
to benefit the public to monitor the operations in issuing
certificates. The logs do not prevent mis-issuing behavior, but the
provided public audibility can increase the possibility in detecting
certain mis-behaviors of issuers. The logs are constructed with
Merkle Hash Trees to ensure the append-only property, and thus enable
anyone to verify the correctness of each log and to monitor when new
certificates are added to it. Note that CT is a common mechanism
although [I-D.ietf-trans-rfc6962-bis] only describe its usage in
publishing TLS server certificates issued by public certificate
authorities (CAs).
This document discusses the application of CT to publicly logging the
public keys used by DNSSEC. DNSSEC distributes public keys to
provide origin authentication and integrity protection for DNS
resource records. In order to prove the validity of keys used for
Zhang Expires January 23, 2015 [Page 2]
Internet-Draft CT-DNSSEC July 2014
signing DNS data, DNSSEC uses DNS public key (DNSKEY) RRsets and
Delegation Signer (DS) RRsets to form authentication chains for the
signed data, with each link in the chains vouching for the next. If
an authentication chain can be eventually connected to the a trsuted
public key, the client can then ensure the key for signing the data
is valid.
The application of CT to publish the existence of (DNSKEY) RRsets and
(DS) RRsets can benefit the detection of misissurance of DNSSEC keys.
For instance, if the owner of foo.example.com finds that its parent
zone (example.com) publish a DS RR for its zone which however does
not point to any legal zone signing keys or key signing keys, the
owner can claim that a mississuance event occures.
This work re-use some text in [I-D.ietf-trans-rfc6962-bis].
2. Cryptographic Components of Certificate Transparency
The introduce of cryptographic components of CT is in Section 2 of
[I-D.ietf-trans-rfc6962-bis]. When applying CT for NDSSEC, a log is
a single, ever-growing, append-only Merkle Tree of DNSKEY and DS RRs.
3. Log Format and Operation
When generating a new DNSKEY RR or a DS RR (i.e., during the
publication of a KSK or a zone authentication key), a zone owner will
publish the RR to the CT logs. Because a key will not be trusted by
clients unless logged, it is expected that a zone owner will usually
deliver the RRs (keys) for audit purposes.
Identical to what is specified in [I-D.ietf-trans-rfc6962-bis],when a
valid DNSKEY RR or a valid DS RR is submitted to a log, the log MUST
immediately return a Signed Certificate Timestamp (SCT). The SCT is
the log's promise to incorporate the RR in the Merkle Tree within a
fixed amount of time known as the Maximum Merge Delay (MMD). If the
log has previously seen the certificate, it MAY return the same SCT
as it returned before. DNS servers MUST provide an SCT from one or
more logs to the client within a SCT RR. DNS clients MUST NOT trust
a key that does not have a valid SCT.
3.1. Log Entries
A zone owner can submit a DNSKEY or DS RR to any log before
publishing the RR. In order to enable attribution of each logged RR
to its issuer, the log SHALL publish a list of acceptable zone
signing public keys (or hashes of public keys) of root zones or
islands of security. Each submitted RR MUST be accompanied by all
additional RRs (DNSKEY RRs, DS RRs, and RRSIG RRs) which construct an
Zhang Expires January 23, 2015 [Page 3]
Internet-Draft CT-DNSSEC July 2014
authentication chain to an accepted root public key. Note that the
NSEC RR is not provided since the existence of this type of RR
indicates the broken of an authentication chain.
A typical authentication chain is Public
Key->[DS->(DNSKEY)*->DNSKEY]*->RRset, where "*" denotes zero or more
subchains. (DNSKEY)* indicates that DNSSEC permits additional layers
of DNSKEY RRs signing other DNSKEY RRs within a zone. Each DNSKEY/DS
RR in the chain is authenticated by a RRSIG RR. In practice, a RRSIG
RR may be used to sign a DS/DNSKEY RRset rather than a single RR. In
this case, not only the DS/DNSKEY RR on the authentication chain but
also other records in the RRset SHOULD be provided to the log the
verification purpose. Otherwise, the log may have to consult DNS
again in order to verify the authentication chains.
4. Including the Signed Certificate Timestamp into DNS Security
Extensions
4.1. SCT RR
The SCT associated with a DNSKEY/ DS RR is stored within a STC RR.
The type number for the DS record is TBD1.
The DS resource record is class independent.
The DS RR has no special TTL requirements.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | Algorithm | Digest Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Digest /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ STC /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1. The Key Tag Field
The Key Tag field lists the key tag of the DNSKEY RR referred to by
the SCT record, in network byte order. Appendix B of [RFC4034]
describes how to compute a Key Tag.
Zhang Expires January 23, 2015 [Page 4]
Internet-Draft CT-DNSSEC July 2014
4.1.2. The Algorithm Field
The Algorithm field lists the algorithm number of the DNSKEY RR
referred to by the SCT record. Appendix A.1 of [RFC4034] lists the
algorithm number types.
4.1.3. The Digest Type Field
The Digest Type field identifies the algorithm used to construct the
digest used to identify the DNSKEY RR that the SCT RR refers to.
Appendix A.2 of [RFC4034] lists the possible digest algorithm types.
4.1.4. The Digest Field
The method of calculating digest is identical to what is specified in
Section 5.1.4 of [RFC4034]
4.1.5. The SCT Field
This field contains the SCT got from the log.
4.2. Operations
After introducing the SCT RR, the verification procedures of DNS data
specified in DNSSEC[RFC4305] do not change a lot. However, the
correctness of CTS needs to be assessed during checking the validity
of a NDSKEY/DS RR.
A NDSKEY/DS RR needs to be associated with a CTS RR which contains a
valid CTS and signed with a proper public key. Otherwise, the
NDSKEY/DS RR will not be used to construct the authentication chain.
The signatures of NDSKEY/DS RR and its CTS RR should be stored in
different RRSIG RR respectively. In addition, a DNS server will
sends CTS RRs and the associated RRSIG RRs to a resolver only when it
indicates the support of CT in the request.
5. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
Zhang Expires January 23, 2015 [Page 5]
Internet-Draft CT-DNSSEC July 2014
6.1. Logging other types of RRs
The above section tries to propose a solution to disclose keys for
DNSSEC in logs for the public to audit. However, it may be valuable
to also log the RRs specified in [RFC1035]. For instance, assume
there is an attacker which has compromised the zone authentication
key and is able to perform the MITM attack between a resolver and the
DNS server of the zone. It is possible for an attacker to transfer a
forged RR which is signed with the compromised key. The current
solution cannot benefit the detection of this attack in this
scenario. However, if the RR is also required to be uploaded to
public logs, the condition is changed. If the attacker does not
publish the RR to a log, it cannot get the SCT. When the attacker
tries to publish the RR to the log, the owner of the zone may detect
the problem even if the attacker can provide keys to convince the log
to accept the RR.
7. Acknowledgements
8. Normative References
[I-D.ietf-trans-rfc6962-bis]
Laurie, B., Langley, A., Kasper, E., and R. Stradling,
"Certificate Transparency", draft-ietf-trans-
rfc6962-bis-04 (work in progress), July 2014.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005.
Author's Address
Dacheng Zhang
Huawei
Email: zhangdacheng@huawei.com
Zhang Expires January 23, 2015 [Page 6]
