Use of DNS CERT Records for Key Assurance

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

1. Requirements Language
2. Introduction
    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
        3.1.1. DPKIX
        3.1.2. DPTR
    3.2. X.509v3 Extension
    3.3. Processing Rules
        3.3.1. General
        3.3.2. Transport layer Security
        3.3.3. Service Discovery (SRV, NAPTR)
4. Security Considerations
    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
        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
        4.3.7. Protocol Substitution Attack
        4.3.8. Protocol Downgrade Attack
    4.4. User Notification
        4.4.1. Certificate Data
5. IANA Considerations
6. Acknowledgements
7. References
    7.1. Normative References
    7.2. Non-Normative References
Appendix A. Appendix - Design Choices
    A.1. Key Digest
§ Author's Address

1. Requirements Language

2. Introduction

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

The CERT resource record (RR) has the structure given below. Its RR type code is 37.

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

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

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.

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

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

7.2. Non-Normative References

Appendix A. Appendix - Design Choices

A.1. Key Digest

The use of CERT type for digests of keys as opposed to complete certificates was considered and rejected.

[RFC2119]	Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4033]	Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” RFC 4033, March 2005 (TXT).
[RFC4034]	Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” RFC 4034, March 2005 (TXT).
[RFC4035]	Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” RFC 4035, March 2005 (TXT).
[RFC4398]	Josefsson, S., “Storing Certificates in the Domain Name System (DNS),” RFC 4398, March 2006 (TXT).
[RFC5246]	Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT).

[RFC4025]	Richardson, M., “A Method for Storing IPsec Keying Material in DNS,” RFC 4025, March 2005 (TXT).
[RFC4255]	Schlyter, J. and W. Griffin, “Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints,” RFC 4255, January 2006 (TXT).

	Phillip Hallam-Baker
	Comodo Inc.
Email:	philliph@comodo.com

Use of DNS CERT Records for Key Assurancedraft-hallambaker-certhash-00

Abstract