Network Working Group Jiankang. Yao
Internet-Draft Jian. Jin
Intended status: Standards Track Wei. Mao
Expires: February 12, 2011 CNNIC
August 11, 2010
Alias algorithm identifier assignment mechanism for DNSSEC
draft-yao-dnsext-alias-algorithm-00.txt
Abstract
DNS Security Extensions (DNSSEC) has been developed to provide origin
authentication and integrity protection for DNS data by using digital
signatures. The DNSKEY, RRSIG, and DS RRs use an 8-bit number to
identify the security algorithm being used. More and more new
RRTYPEs will appear in future. This document defines an alias
algorithm identifier assignment method for DNSSEC 8-bit algorithm
numbers.
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 February 12, 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
Yao, et al. Expires February 12, 2011 [Page 1]
Internet-Draft alias-alg August 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Alias algorithm identifer assignment . . . . . . . . . . . 3
4. Validating the RRSIG for the new RRTYPE . . . . . . . . . . . . 4
5. Compatiliable with the old vaildating resolver . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. draft-yao-dnsext-alias-algorithm: Version 00 . . . . . . . 5
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
10.1. Normative References . . . . . . . . . . . . . . . . . . . 5
10.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Yao, et al. Expires February 12, 2011 [Page 2]
Internet-Draft alias-alg August 2010
1. Introduction
The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034], [RFC4035]
and [RFC5155] were developed to provide origin authentication and
integrity protection for DNS data by using digital signatures. Every
DNSKEY, RRSIG, or DS RR contains an algorithm code number. These
algorithm numbers help validators to identify which cryptographic
algorithm was used. The algorithm numbers which can be used is
within 256. More RRTYPES will appear in future. The new RRTYPE may
use the alias algorithm number. In order to prevent the new RRTYPE
unaware resolvers from attempting to validate responses from the
RRTYPE signed zones, some specification might request to allocates
the new DNSKEY alias algorithm identifiers for the current algorithms
used. For example Algorithm 6, DSA-NSEC3-SHA1 is an alias for
algorithm 3, DSA. This is not a new algorithm, just an additional
identifiers for the existing algorithm. The new RRTYPE unaware
resolvers will not know these new identifiers and treat responses
from the new RRTYPE signed zone as insecure, otherwise the new RRTYPE
RR will be regarded as bogus if there is no such a mechanism. Using
other alias algorithms for the new RRTYPE requires allocation of a
new alias algorithm numbers. Based on the rule of first come first
served, the 8-bit algorithm allocation pool would soon be exhausted
if more and more new RRTYPEs and algorithms had appeared in the DNS
protocols. This document defines an alias algorithm number
assignment for the DNSSEC 8-bit algorithm numbers.
1.1. Terminology
All the basic terms used in this specification are defined in the
documents [RFC1034] and [RFC1035]. DNSSEC related terms are defined
in [RFC4033], [RFC4034], and [RFC4035]
2. Motivation
This document tackles the problem that the new RRTYPE requests the
alias algorithm number assignment but the algorithm number space is
not enough.
3. The Alias algorithm identifer assignment
Every algorithm identifier that might be used for the new RRTYPE
should have the alias identifier. Based on the current algorithm
which has been allocated, the follow algorithm should have the alias
identifier number:
Yao, et al. Expires February 12, 2011 [Page 3]
Internet-Draft alias-alg August 2010
+-------------------+-----------------+-------------------+
| Description | Mnemonic | Original Mnemonic |
+-------------------+-----------------+-------------------+
| Diffie-Hellman | alias-dh | DH |
| DSA/SHA1 | alias-DSA-SHA1 | DSA/SHA1 |
| URSA/SHA-1 | alias-RSASHA1 | RSASHA1 |
| RSA/SHA-256 | alias-RSASHA256 | RSASHA256 |
| RSA/SHA-512 | alias-RSASHA512 | RSASHA512 |
| GOST R 34.10-2001 | alias-ECC-GOST | ECC-GOST |
+-------------------+-----------------+-------------------+
Other algorithm's alias identifiers will be assigned in future
according to the future requirements.
4. Validating the RRSIG for the new RRTYPE
The validating resolver following this specification MUST check the
type covered of the RRSIG before the verification. Only when the
validating resolver knows the RRTYPE, it can begin to verify the
signature of the RRSIG. Otherwise, the validating resolver MUST
regard the RRSIG in which the type covered is unknown to the resolver
as insecure instead of bogus.
5. Compatiliable with the old vaildating resolver
The old validating resolver deployed will not know the new identifier
for the algorithm. Zones signed according to this new specification
MUST only use these alias algorithm identifiers for their DNSKEY RRs
if there has the new RRTYPE in the zone. The old resolver will treat
the RRSIG whose algorithm identifier is unknown to them as insecure,
otherwise the RR with the new type will be regarded as bogus if there
is no such a mechanism.
6. IANA Considerations
This document updates the IANA registry "DNS SECURITY ALGORITHM
NUMBERS". IANA is requested to assign the algorithm number to the
following alias algorithm identifier.
Yao, et al. Expires February 12, 2011 [Page 4]
Internet-Draft alias-alg August 2010
+--------+-------------------+-----------------+-------------------+
| Number | Description | Mnemonic | Original Mnemonic |
+--------+-------------------+-----------------+-------------------+
| XX1 | Diffie-Hellman | alias-dh | DH |
| XX2 | DSA/SHA1 | alias-DSA-SHA1 | DSA/SHA1 |
| XX3 | URSA/SHA-1 | alias-RSASHA1 | RSASHA1 |
| XX4 | RSA/SHA-256 | alias-RSASHA256 | RSASHA256 |
| XX5 | RSA/SHA-512 | alias-RSASHA512 | RSASHA512 |
| XX6 | GOST R 34.10-2001 | alias-ECC-GOST | ECC-GOST |
+--------+-------------------+-----------------+-------------------+
7. Security Considerations
TBD
8. Acknowledgements
Many ideas are from the discussion in the DNSOP and DNSEXT mailing
list. Thanks a lot to all in the list. Many important comments and
suggestions are contributed by many members of the DNSEXT and DNSOP
WGs. Thanks a lot to the DNS team members of CNNIC such as zhng li
kun, han feng and sun guo nian.
9. Change History
[[anchor9: RFC Editor: Please remove this section.]]
9.1. draft-yao-dnsext-alias-algorithm: Version 00
o the initial version
10. References
10.1. Normative References
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
Yao, et al. Expires February 12, 2011 [Page 5]
Internet-Draft alias-alg August 2010
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[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.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
10.2. Informative References
[RFC2672bis]
Rose, S. and W. Wijngaards, "Update to DNAME Redirection
in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname-
17.txt, 6 2009.
Authors' Addresses
Jiankang YAO
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58813007
Email: yaojk@cnnic.cn
Yao, et al. Expires February 12, 2011 [Page 6]
Internet-Draft alias-alg August 2010
Jian Jin
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58813000
Email: jinjian@cnnic.cn
Wei MAO
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58812230
Email: maowei_ietf@cnnic.cn
Yao, et al. Expires February 12, 2011 [Page 7]