Internet DRAFT - draft-hallambaker-certhash
draft-hallambaker-certhash
Internet Engineering Task Force P. Hallam-Baker
Internet-Draft Comodo Inc.
Intended status: Informational September 10, 2010
Expires: March 14, 2011
Use of DNS CERT Records for Key Assurance
draft-hallambaker-certhash-00
Abstract
Deployment of DNSSEC opens up the possibility of new mechanisms for
assuring application keys. This document extends the use of the DNS
CERT resource record and defines X.509v3 extensuions to support key
assurance mechanisms for use with TLS and other X.509 protocols and
provides a comprehensive assessment of the security thus achieved.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to format it
for publication as an RFC or to translate it into languages other
than English.
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 March 14, 2011.
Copyright Notice
Copyright (c) 2010 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
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
Hallam-Baker Expires March 14, 2011 [Page 1]
Internet-Draft DNS CERT Records for Key Assurance September 2010
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. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. DNS CERT Resource Record . . . . . . . . . . . . . . . 4
2.2. Public Key Infrastructure . . . . . . . . . . . . . . . . 4
2.2.1. Public Key Infrastructure X.509 . . . . . . . . . . . 4
2.3. Public Key Security Protocols . . . . . . . . . . . . . . 4
2.3.1. Transport Layer Security . . . . . . . . . . . . . . . 4
2.3.2. IP Security . . . . . . . . . . . . . . . . . . . . . 4
2.3.3. Use in Applications . . . . . . . . . . . . . . . . . 4
3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. CERT Resource Record Parameters . . . . . . . . . . . . . 4
3.1.1. DPKIX . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. DPTR . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. X.509v3 Extension . . . . . . . . . . . . . . . . . . . . 7
3.3. Processing Rules . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Transport layer Security . . . . . . . . . . . . . . . 7
3.3.3. Service Discovery (SRV, NAPTR) . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4.1. Trust Chain Assurance . . . . . . . . . . . . . . . . . . 8
4.1.1. Root of Trust . . . . . . . . . . . . . . . . . . . . 8
4.1.2. Non Repudiation . . . . . . . . . . . . . . . . . . . 8
4.1.3. Key Revocation . . . . . . . . . . . . . . . . . . . . 8
4.2. DNSSEC Operations . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Signature Time To Live . . . . . . . . . . . . . . . . 8
4.2.2. Zone Signing Key Compromise . . . . . . . . . . . . . 8
4.2.3. Key Signing Key Compromise . . . . . . . . . . . . . . 8
4.3. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. Suppressed DNSSEC records . . . . . . . . . . . . . . 8
4.3.2. Replay Attack of DNSSEC records . . . . . . . . . . . 8
4.3.3. Zone Hijack . . . . . . . . . . . . . . . . . . . . . 8
4.3.4. Disclosure of End Entity Key . . . . . . . . . . . . . 8
4.3.5. Disclosure of DNSSEC Key . . . . . . . . . . . . . . . 8
4.3.6. Malicious Domain Name Holder . . . . . . . . . . . . . 8
4.3.7. Protocol Substitution Attack . . . . . . . . . . . . . 9
4.3.8. Protocol Downgrade Attack . . . . . . . . . . . . . . 9
4.4. User Notification . . . . . . . . . . . . . . . . . . . . 9
4.4.1. Certificate Data . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
Hallam-Baker Expires March 14, 2011 [Page 2]
Internet-Draft DNS CERT Records for Key Assurance September 2010
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Non-Normative References . . . . . . . . . . . . . . . . . 10
Appendix A. Appendix - Design Choices . . . . . . . . . . . . . . 11
A.1. Key Digest . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Hallam-Baker Expires March 14, 2011 [Page 3]
Internet-Draft DNS CERT Records for Key Assurance September 2010
1. 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. Introduction
The DNS CERT resource record defined in RFC 4398 [RFC4398] specifies
the use of the DNS for discovery of public keys associated with a
domain.
2.1. DNS
2.1.1. DNSSEC
2.1.2. DNS CERT Resource Record
2.2. Public Key Infrastructure
2.2.1. Public Key Infrastructure X.509
2.3. Public Key Security Protocols
2.3.1. Transport Layer Security
2.3.2. IP Security
2.3.3. Use in Applications
3. Mechanism
3.1. CERT Resource Record Parameters
Two new CERT certificate types are defined:
DPKIX
DPTR
The CERT resource record (RR) has the structure given below. Its RR
type code is 37.
Hallam-Baker Expires March 14, 2011 [Page 4]
Internet-Draft DNS CERT Records for Key Assurance September 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | key tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | /
+---------------+ certificate data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
The type field is the certificate type as defined below.
The key tag field used for key selection as specified in RFC 4034
[RFC4034] Section 5.1.1.
The algorithm field is the algorithm code for the digest algorithm as
specified in the IANA registry Delegation Signer (DS) Resource Record
(RR) Type Digest Algorithms.
3.1.1. DPKIX
The DPKIX certificate type asserts a binding between the DNS domain
in which it is published and the subject key specified in a PKIX
certificate identified by means of a cryptographic digest function.
The assertion made by means of the DPKIX certificate type is only as
secure as the trust chain that authenticates it. Trust chain
processing rules are specified in Section XXX below.
In particular the presence of a DPKIX record in a DNS domain that is
not signed using DNSSEC or other security mechanism SHOULD NOT be
considered to provide any additional assurance that would not be
provided by the certificate on its own.
In the case that a DPKIX record exists and contains a digest value
that matches the digest value of the certificate and is signed by a
verified signature, a relying party MAY infer an assertion on the
part of the domain name holder that the specified key is bound to the
specified certificate subject key. No other properties of the
certificate may be considered to have been assured excepting those
that limit the use of the certificate which MUST be observed as with
any other PKIX certificate. Such properties include the notBefore
and notAfter fields, the key Usage bits and all X.509v3 extensions
for which the critical bit is set.
The CERT record field values are defined for DPKIX as follows:
Hallam-Baker Expires March 14, 2011 [Page 5]
Internet-Draft DNS CERT Records for Key Assurance September 2010
Type is set to the value (TBS IANA)
Key tag MUST be set to 1
Algorithm contains the algorithm code for the digest algorithm.
Certificate data contains the digest value of the certificate for
which a binding between the subject key and the domain name is
asserted
example.com CERT DPKIX 1 SHA256
KR1L0GbocaIOOim1+qdHtOSrDcOsGiI2NCcxuX2/Tqc
3.1.2. DPTR
The DPTR certificate type allows an unlimited number of certificates
to be bound to a single DNS domain name overcomming the limitations
that the DNS protocol imposes on the number of CERT records that can
be bound to a single DNS domain name in a practical deployment.
The CERT record field values are defined for DPTR as follows:
Type is set to the value (TBS IANA)
Key tag MUST be set to 1
Algorithm contains the algorithm code for the digest algorithm to
be used to calculate Cselector prefixes.
Certificate data contains the DNS name to be used as the root node
to which the calculated selectorn prefix is prepended.
The PKIX certificate for which the assurance is being saught is
processed using the specified digest algorithm to produce a digest
value which is converted to base 64 according to the mechanism
specified in [] and has an underscore character '_' prepended to form
a selector label as follows:
selector = "_" + base64 ( digest ( certificate))
The key selector label is prepended to the domain name specified to
form a DNS domain name on which a DNS query for a CERT resource
record is to be performed.
query_name = selector + "." + domain_name
The following example shows the use of the DPTR certificate type to
Hallam-Baker Expires March 14, 2011 [Page 6]
Internet-Draft DNS CERT Records for Key Assurance September 2010
provide an assurance for the same certificate specified earlier.
example.com CERT DPTR 1 SHA256 "cert.example.com"
_KR1L0GbocaIOOim1+qdHtOSrDcOsGiI2NCcxuX2/Tqc.cert.example.com DPKIX
1 SHA256 KR1L0GbocaIOOim1+qdHtOSrDcOsGiI2NCcxuX2/Tqc
The DPTR certificate type can only be resolved after the certificate
for which the assurance is required is known. It is thus not
possible to pre-fetch the certificate at the same time that A or AAAA
record is performed as is the case when the DPKIX certificate type is
populated at the domain name for which the assurance is being made.
3.2. X.509v3 Extension
The X.509v3 certificate extension 'DNS-CERT' MAY be included in an
X.509v3 certificate to notify relying parties that a DNS key
assurance MAY or MUST be employed.
If the DNS-CERT extension is present and the critical flag bit is not
set, it serves as a notice to a relying party applications that they
MAY attempt to use the key assurance mechanism specified in this
document.
If the DNS-CERT extension critical flag bit is set, a relying party
application MUST support the key assurance mechanism specified in
this document and MUST NOT consider the certificate valid unless the
outcome of the verification procedure is 'verified'.
Since applications MUST NOT make use of X.509v3 critical extensions
that are not understood, use of the critical flag bit value 'set' is
strongly discouraged. Certificate issuers SHOULD NOT set the
critical flag bit on a DNS-CERT unless this is the derisred behavior
3.3. Processing Rules
3.3.1. General
3.3.2. Transport layer Security
3.3.3. Service Discovery (SRV, NAPTR)
4. Security Considerations
Hallam-Baker Expires March 14, 2011 [Page 7]
Internet-Draft DNS CERT Records for Key Assurance September 2010
4.1. Trust Chain Assurance
4.1.1. Root of Trust
4.1.2. Non Repudiation
4.1.3. Key Revocation
4.2. DNSSEC Operations
4.2.1. Signature Time To Live
4.2.2. Zone Signing Key Compromise
4.2.3. Key Signing Key Compromise
4.3. Attacks
We have considered possible protocol attacks by identifying protocol
assets, the abstract risks to which such assets may be exposed and
how such risks may be manifest in concrete threats.
The assets considered are the DNSSEC private keys held by the domain
name holder, DNS zone in which the resorce records are presented and
the application public key pair.
The DNS is a large infrastructure and management of a specific DNS
zone is never within the unique control of one party. In addition to
considering means of preventing compromise we consider the steps
required to recover from a compromise.
4.3.1. Suppressed DNSSEC records
4.3.2. Replay Attack of DNSSEC records
4.3.3. Zone Hijack
4.3.4. Disclosure of End Entity Key
4.3.5. Disclosure of DNSSEC Key
4.3.6. Malicious Domain Name Holder
A signed CERT record only demonstrates that the party in control of
the authoritative DNS zerver for the specified zone has authorized
the use of a particular public key for authenticating communication
with the server.
Hallam-Baker Expires March 14, 2011 [Page 8]
Internet-Draft DNS CERT Records for Key Assurance September 2010
A signed CERT record does not and cannot express any assertion
concerning the existence, trustworthiness or accountability of either
the key holder or the domain name holder.
4.3.7. Protocol Substitution Attack
for the purposes of establishing a secure connection, an end entity
certificate assured by means of a signed CERT record MUST meet all
the requirements that any other end entity certificate is required to
meed for use with that protocol.
If protection against a protocol substitution attack is required, the
signer of the end entity certificate SHOULD ensure that the
appropriate X.509 Key Usage, Extended Key Usage and/or extensions are
appropriately configured.
4.3.8. Protocol Downgrade Attack
The CERT record only provides notice that a public key is associated
with a DNS domain name. The mere presence of a CERT record at a DNS
node does not imply that its use is supported in conjunction with a
specific protocol.
Accordingly, use of CERT records does not and cannot provide
protection against protocol downgrade attacks.
4.4. User Notification
Relying party applciations MAY notify the user that a cryptographic
security protocol is in use to protect the confidentiality and
integrity of communication with the domain name holder.
Key assurance by means of the CERT mechanism only extends to the
properties of the key itself and the security of the connection
established to the Internet service provided by the key holder. Key
Assurance by means of the CERT mechanism does not and cannot support
any assertion regarding the trustworthiness of either the key holder
or the domain name holder.
A secure connection to an endpoint identified by a domain name alone
does not imply a secure transaction. If provided, a user
notification MUST NOT imply that a user is 'safe' on the basis of
CERT key assurance alone.
4.4.1. Certificate Data
The only data inside a
Hallam-Baker Expires March 14, 2011 [Page 9]
Internet-Draft DNS CERT Records for Key Assurance September 2010
5. IANA Considerations
The IANA maintains theregistry for CERT RR: certificate types. The
following additional certificate types should be added to the
registry at the next available code point:
Decimal Type Meaning Reference
------- ---- ------- ---------
9 DPKIX Digest value of X.509 as per PKIX [This]
10 SIHLOK Indirection Pointer [This]
6. Acknowledgements
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name
System (DNS)", RFC 4398, March 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
7.2. Non-Normative References
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005.
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
Hallam-Baker Expires March 14, 2011 [Page 10]
Internet-Draft DNS CERT Records for Key Assurance September 2010
January 2006.
Appendix A. Appendix - Design Choices
This section provides rationales for design choices adopted in this
draft.
A.1. Key Digest
The use of CERT type for digests of keys as opposed to complete
certificates was considered and rejected.
Author's Address
Phillip Hallam-Baker
Comodo Inc.
Email: philliph@comodo.com
Hallam-Baker Expires March 14, 2011 [Page 11]
