draft-ietf-dnsext-rsa-00.txt | draft-ietf-dnsext-rsa-01.txt | |||
---|---|---|---|---|

INTERNET-DRAFT RSA SIGs and KEYs in the DNS | INTERNET-DRAFT RSA SIGs and KEYs in the DNS | |||

OBSOLETES RFC 2537 August 2000 | OBSOLETES RFC 2537 September 2000 | |||

Expires February 2001 | Expires March 2001 | |||

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-00.txt> | <draft-ietf-dnsext-rsa-01.txt> | |||

D. Eastlake 3rd | 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 | |||

skipping to change at page 2, line 7 | skipping to change at page 2, line 7 | |||

Since the adoption of a Proposed Standard for RSA signatures in the | Since the adoption of a Proposed Standard for RSA signatures in the | |||

DNS [RFC 2537], advances in hashing have been made. A new DNS | DNS [RFC 2537], advances in hashing have been made. A new DNS | |||

signature algorithm is defined to make these advances available in | signature algorithm is defined to make these advances available in | |||

SIG resource records (RRs). The use of the previously specified | SIG resource records (RRs). The use of the previously specified | |||

weaker mechanism is deprecated. The algorithm number of the RSA KEY | weaker mechanism is deprecated. The algorithm number of the RSA KEY | |||

RR is changed to correspond to this new SIG algorithm. No other | RR is changed to correspond to this new SIG algorithm. No other | |||

changes are made to DNS security. | changes are made to DNS security. | |||

INTERNET-DRAFT RSA/SHA1 in the DNS | INTERNET-DRAFT RSA/SHA1 in the DNS | |||

Acknowledgements | ||||

Material and comments from the following have been incorporated and | ||||

are gratefully acknowledged: | ||||

Olafur Gudmundsson | ||||

Charlie Kaufman | ||||

Table of Contents | Table of Contents | |||

Status of This Document....................................1 | Status of This Document....................................1 | |||

Abstract...................................................1 | Abstract...................................................1 | |||

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

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 31 | skipping to change at page 4, line 31 | |||

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. Or, from another | |||

point of view, adds a new KEY RR with a new algorithm number that is | 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, | otherwise identical to the RSA KEY RR defined in RFC 2537. In fact, | |||

RSA KEYs do not depend on selection of hash algorihtm. An | RSA KEYs do not depend on selection of hash algorithm. An | |||

alternative would be to leave RSA KEY RRs unchanged and indicated by | alternative would be to leave RSA KEY RRs unchanged and indicated by | |||

algorithm 1.] | 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 [RFC 1321], | 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, | |||

INTERNET-DRAFT RSA/SHA1 in the DNS | hex 30 21 30 1F 06 05 2B 0E 03 02 1A 05 00 04 14 | |||

hex (to be supplied). | ||||

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

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].) | Public Key Cryptographic Standard #1 [RFC 2437]. The value for | |||

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 5, line 47 | skipping to change at page 6, line 4 | |||

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

INTERNET-DRAFT RSA/SHA1 in the DNS | ||||

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

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

skipping to change at page 8, line 19 | skipping to change at page 8, line 19 | |||

Donald E. Eastlake 3rd | Donald E. Eastlake 3rd | |||

Motorola | Motorola | |||

140 Forest Avenue | 140 Forest Avenue | |||

Hudson, MA 01749 USA | Hudson, MA 01749 USA | |||

Telephone: +1-978-562-2827 (h) | Telephone: +1-978-562-2827 (h) | |||

+1-508-261-5434 (w) | +1-508-261-5434 (w) | |||

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 February 2001. | This draft expires in March 2001. | |||

Its file name is draft-eastlake-dnsext-rsa-00.txt. | Its file name is draft-ietf-dnsext-rsa-01.txt. | |||

End of changes. | ||||

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