Network Working Group D. Eastlake 3rd
Request for Comments: 3110 Motorola
Obsoletes: 2537 May 2001
Category: Standards Track
RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document describes how to produce RSA/SHA1 SIG resource records
(RRs) in Section 3 and, so as to completely replace RFC 2537,
describes how to produce RSA KEY RRs in Section 2.
Since the adoption of a Proposed Standard for RSA signatures in the
DNS (Domain Name Space), advances in hashing have been made. A new
DNS signature algorithm is defined to make these advances available
in SIG RRs. The use of the previously specified weaker mechanism is
deprecated. The algorithm number of the RSA KEY RR is changed to
correspond to this new SIG algorithm. No other changes are made to
DNS security.
Acknowledgements
Material and comments from the following have been incorporated and
are gratefully acknowledged:
Olafur Gudmundsson
The IESG
Charlie Kaufman
Steve Wang
D. Eastlake 3rd Standards Track [Page 1]
RFC 3110 RSA SIGs and KEYs in the DNS May 2001
Table of Contents
1. Introduction................................................... 2
2. RSA Public KEY Resource Records................................ 3
3. RSA/SHA1 SIG Resource Records.................................. 3
4. Performance Considerations..................................... 4
5. IANA Considerations............................................ 5
6. Security Considerations........................................ 5
References........................................................ 5
Author's Address.................................................. 6
Full Copyright Statement.......................................... 7
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information [RFC1034, 1035, etc.]. The DNS has been extended
to include digital signatures and cryptographic keys as described in
[RFC2535]. Thus the DNS can now be secured and used for secure key
distribution.
Familiarity with the RSA and SHA-1 algorithms is assumed [Schneier,
FIP180] in this document.
RFC 2537 described how to store RSA keys and RSA/MD5 based signatures
in the DNS. However, since the adoption of RFC 2537, continued
cryptographic research has revealed hints of weakness in the MD5
[RFC1321] algorithm used in RFC 2537. The SHA1 Secure Hash Algorithm
[FIP180], which produces a larger hash, has been developed. By now
there has been sufficient experience with SHA1 that it is generally
acknowledged to be stronger than MD5. While this stronger hash is
probably not needed today in most secure DNS zones, critical zones
such a root, most top level domains, and some second and third level
domains, are sufficiently valuable targets that it would be negligent
not to provide what are generally agreed to be stronger mechanisms.
Furthermore, future advances in cryptanalysis and/or computer speeds
may require a stronger hash everywhere. In addition, the additional
computation required by SHA1 above that required by MD5 is
insignificant compared with the computational effort required by the
RSA modular exponentiation.
This document describes how to produce RSA/SHA1 SIG RRs in Section 3
and, so as to completely replace RFC 2537, describes how to produce
RSA KEY RRs in Section 2.
Implementation of the RSA algorithm in DNS with SHA1 is MANDATORY for
DNSSEC. The generation of RSA/MD5 SIG RRs as described in RFC 2537
is NOT RECOMMENDED.
D. Eastlake 3rd Standards Track [Page 2]
RFC 3110 RSA SIGs and KEYs in the DNS May 2001
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", "NOT
RECOMMENDED", and "MAY" in this document are to be interpreted as
described in RFC 2119.