draft-ietf-dnsext-rsa-01.txt   draft-ietf-dnsext-rsa-02.txt 
INTERNET-DRAFT RSA SIGs and KEYs in the DNS INTERNET-DRAFT RSA SIGs and KEYs in the DNS
OBSOLETES RFC 2537 September 2000 OBSOLETES RFC 2537 December 2000
Expires March 2001 Expires June 2001
D. Eastlake
RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
--------- ---- --- --- ---- -- --- ------ ---- ------ ----- --------- ---- --- --- ---- -- --- ------ ---- ------ -----
<draft-ietf-dnsext-rsa-01.txt> <draft-ietf-dnsext-rsa-02.txt>
D. Eastlake 3rd
Status of This Document Status of This Document
This draft is intended to be become a Proposed Standard RFC. This draft is intended to be become a Proposed Standard RFC.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
to the DNS extensions mailing list <namedroppers@ops.ietf.org> or to to the DNS extensions mailing list <namedroppers@ops.ietf.org> or to
the author. the author.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are all provisions of Section 10 of RFC 2026. Internet-Drafts are
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Acknowledgements Acknowledgements
Material and comments from the following have been incorporated and Material and comments from the following have been incorporated and
are gratefully acknowledged: are gratefully acknowledged:
Olafur Gudmundsson Olafur Gudmundsson
Charlie Kaufman Charlie Kaufman
Steve Wang
Table of Contents Table of Contents
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................1 Abstract...................................................1
Acknowledgements...........................................2 Acknowledgements...........................................2
Table of Contents..........................................2 Table of Contents..........................................2
1. Introduction............................................3 1. Introduction............................................3
2. RSA Public KEY Resource Records.........................3 2. RSA Public KEY Resource Records.........................3
3. RSA/SHA1 SIG Resource Records...........................4 3. RSA/SHA1 SIG Resource Records...........................4
4. Performance Considerations..............................5 4. Performance Considerations..............................5
5. IANA Considerations.....................................6 5. IANA Considerations.....................................5
6. Security Considerations.................................6 6. Security Considerations.................................6
References.................................................7 References.................................................7
Author's Address...........................................8 Author's Address...........................................8
Changes from last draft....................................8
Expiration and File Name...................................8 Expiration and File Name...................................8
INTERNET-DRAFT RSA/SHA1 in the DNS INTERNET-DRAFT RSA/SHA1 in the DNS
1. Introduction 1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and distributed database system for Internet addressing, mail proxy, and
other information [RFC 1034, 1035, etc.]. The DNS has been extended other information [RFC 1034, 1035, etc.]. The DNS has been extended
to include digital signatures and cryptographic keys as described in to include digital signatures and cryptographic keys as described in
skipping to change at page 4, line 27 skipping to change at page 4, line 27
two octet unsigned length if it is longer than 255 bytes. The public two octet unsigned length if it is longer than 255 bytes. The public
key modulus field is a multiprecision unsigned integer. The length key modulus field is a multiprecision unsigned integer. The length
of the modulus can be determined from the RDLENGTH and the preceding of the modulus can be determined from the RDLENGTH and the preceding
RDATA fields including the exponent. Leading zero octets are RDATA fields including the exponent. Leading zero octets are
prohibited in the exponent and modulus. prohibited in the exponent and modulus.
Note: KEY RRs for use with RSA/SHA1 DNS signatures MUST use this Note: KEY RRs for use with RSA/SHA1 DNS signatures MUST use this
algorithm number (rather than the algorithm number specified in the algorithm number (rather than the algorithm number specified in the
obsoleted [RFC 2537]). obsoleted [RFC 2537]).
[Note: This changes the algorithm number for RSA KEY RRs to be the Note: This changes the algorithm number for RSA KEY RRs to be the
same as the new algorithm number for RSA/SHA1 SIGs. Or, from another same as the new algorithm number for RSA/SHA1 SIGs.
point of view, adds a new KEY RR with a new algorithm number that is
otherwise identical to the RSA KEY RR defined in RFC 2537. In fact,
RSA KEYs do not depend on selection of hash algorithm. An
alternative would be to leave RSA KEY RRs unchanged and indicated by
algorithm 1.]
3. RSA/SHA1 SIG Resource Records 3. RSA/SHA1 SIG Resource Records
RSA/SHA1 signatures are stored in the DNS using SIG resource records RSA/SHA1 signatures are stored in the DNS using SIG resource records
(RRs) with algorithm number (TBD, 5 suggested). (RRs) with algorithm number (TBD, 5 suggested).
The signature portion of the SIG RR RDATA area, when using the The signature portion of the SIG RR RDATA area, when using the
RSA/SHA1 algorithm, is calculated as shown below. The data signed is RSA/SHA1 algorithm, is calculated as shown below. The data signed is
determined as specified in [RFC 2535]. See [RFC 2535] for fields in determined as specified in [RFC 2535]. See [RFC 2535] for fields in
the SIG RR RDATA which precede the signature itself. the SIG RR RDATA which precede the signature itself.
hash = SHA1 ( data ) hash = SHA1 ( data )
signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n) signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n)
INTERNET-DRAFT RSA/SHA1 in the DNS where SHA1 is the message digest algorithm documented in [FIP180],
where SHA1 is the message digest algorithm documented in [RFC 1321],
"|" is concatenation, "e" is the private key exponent of the signer, "|" is concatenation, "e" is the private key exponent of the signer,
and "n" is the modulus of the signer's public key. 01, FF, and 00 and "n" is the modulus of the signer's public key. 01, FF, and 00
are fixed octets of the corresponding hexadecimal value. "prefix" is are fixed octets of the corresponding hexadecimal value. "prefix" is
the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1 [RFC the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1 [RFC
2437], that is, 2437], that is,
hex 30 21 30 1F 06 05 2B 0E 03 02 1A 05 00 04 14 hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
This prefix is included to make it easier to use standard This prefix is included to make it easier to use standard
cryptographic libraries. The FF octet MUST be repeated the maximum cryptographic libraries. The FF octet MUST be repeated the maximum
INTERNET-DRAFT RSA/SHA1 in the DNS
number of times such that the value of the quantity being number of times such that the value of the quantity being
exponentiated is one octet shorter than the value of n. exponentiated is one octet shorter than the value of n.
(The above specifications are identical to the corresponding part of (The above specifications are identical to the corresponding part of
Public Key Cryptographic Standard #1 [RFC 2437]. The value for Public Key Cryptographic Standard #1 [RFC 2437].)
prefix was provided by Charlie Kaufman.)
The size of "n", including most and least significant bits (which The size of "n", including most and least significant bits (which
will be 1) MUST be not less than 512 bits and not more than 4096 will be 1) MUST be not less than 512 bits and not more than 4096
bits. "n" and "e" SHOULD be chosen such that the public exponent is bits. "n" and "e" SHOULD be chosen such that the public exponent is
small. These are protocol limits. For a discussion of key size see small. These are protocol limits. For a discussion of key size see
[RFC 2541]. [RFC 2541].
Leading zero bytes are permitted in the RSA/SHA1 algorithm signature. Leading zero bytes are permitted in the RSA/SHA1 algorithm signature.
A public exponent of 3 minimizes the effort needed to verify a A public exponent of 3 minimizes the effort needed to verify a
skipping to change at page 6, line 4 skipping to change at page 5, line 43
generation with DSA is faster than RSA. Key generation is also generation with DSA is faster than RSA. Key generation is also
faster for DSA. However, signature verification is an order of faster for DSA. However, signature verification is an order of
magnitude slower with DSA when the RSA public exponent is chosen to magnitude slower with DSA when the RSA public exponent is chosen to
be small as is recommended for KEY RRs used in domain name system be small as is recommended for KEY RRs used in domain name system
(DNS) data authentication. (DNS) data authentication.
Current DNS implementations are optimized for small transfers, Current DNS implementations are optimized for small transfers,
typically less than 512 bytes including DNS overhead. Larger typically less than 512 bytes including DNS overhead. Larger
transfers will perform correctly and extensions have been transfers will perform correctly and extensions have been
standardized [RFC 2671] to make larger transfers more efficient, it standardized [RFC 2671] to make larger transfers more efficient, it
INTERNET-DRAFT RSA/SHA1 in the DNS
is still advisable at this time to make reasonable efforts to is still advisable at this time to make reasonable efforts to
minimize the size of KEY RR sets stored within the DNS consistent minimize the size of KEY RR sets stored within the DNS consistent
with adequate security. Keep in mind that in a secure zone, at least with adequate security. Keep in mind that in a secure zone, at least
one authenticating SIG RR will also be returned. one authenticating SIG RR will also be returned.
5. IANA Considerations 5. IANA Considerations
The DNSSEC algorithm number (TBD, 5 suggested) is allocated for The DNSSEC algorithm number (TBD, 5 suggested) is allocated for
RSA/SHA1 SIG RRs and RSA KEY RRs. RSA/SHA1 SIG RRs and RSA KEY RRs.
INTERNET-DRAFT RSA/SHA1 in the DNS
6. Security Considerations 6. Security Considerations
Many of the general security consideration in [RFC 2535] apply. Keys Many of the general security consideration in [RFC 2535] apply. Keys
retrieved from the DNS should not be trusted unless (1) they have retrieved from the DNS should not be trusted unless (1) they have
been securely obtained from a secure resolver or independently been securely obtained from a secure resolver or independently
verified by the user and (2) this secure resolver and secure verified by the user and (2) this secure resolver and secure
obtainment or independent verification conform to security policies obtainment or independent verification conform to security policies
acceptable to the user. As with all cryptographic algorithms, acceptable to the user. As with all cryptographic algorithms,
evaluating the necessary strength of the key is essential and evaluating the necessary strength of the key is essential and
dependent on local policy. For particularly critical applications, dependent on local policy. For particularly critical applications,
skipping to change at page 8, line 11 skipping to change at page 8, line 11
[Schneier] - Bruce Schneier, "Applied Cryptography Second Edition: [Schneier] - Bruce Schneier, "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996, John Wiley and protocols, algorithms, and source code in C", 1996, John Wiley and
Sons, ISBN 0-471-11709-9. Sons, ISBN 0-471-11709-9.
INTERNET-DRAFT RSA/SHA1 in the DNS INTERNET-DRAFT RSA/SHA1 in the DNS
Author's Address Author's Address
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Motorola Motorola
140 Forest Avenue 155 Beaver Street
Hudson, MA 01749 USA Milford, MA 01757 USA
Telephone: +1-978-562-2827 (h) Telephone: +1-508-261-5434 (w)
+1-508-261-5434 (w) +1-508-634-2066 (h)
FAX: +1-508-261-4777 (w) FAX: +1-508-261-4777 (w)
EMail: Donald.Eastlake@motorola.com EMail: Donald.Eastlake@motorola.com
Changes from last draft
Add acknowledgements and hex value for signature "prefix".
Expiration and File Name Expiration and File Name
This draft expires in March 2001. This draft expires in June 2001.
Its file name is draft-ietf-dnsext-rsa-01.txt. Its file name is draft-ietf-dnsext-rsa-02.txt.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/