draft-ietf-dnssec-rsa-01.txt | rfc2537.txt | |||
---|---|---|---|---|

INTERNET-DRAFT RSA/MD5 KEYs and SIGs in the DNS | Network Working Group D. Eastlake | |||

October 1998 | Request for Comments: 2537 IBM | |||

Expires April 1999 | Category: Standards Track March 1999 | |||

RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) | RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) | |||

------- ---- --- ---- -- --- ------ ---- ------ ----- | ||||

Donald E. Eastlake 3rd | Status of this Memo | |||

Status of This Document | ||||

This draft, file name draft-ietf-dnssec-rsa-01.txt, is intended to be | ||||

become a Proposed Standard RFC. Distribution of this document is | ||||

unlimited. Comments should be sent to the DNS security mailing list | ||||

<dns-security@tis.com> or to the author. | ||||

This document is an Internet-Draft. Internet-Drafts are working | ||||

documents of the Internet Engineering Task Force (IETF), its areas, | ||||

and its working groups. Note that other groups may also distribute | ||||

working documents as Internet-Drafts. | ||||

Internet-Drafts are draft documents valid for a maximum of six | This document specifies an Internet standards track protocol for the | |||

months. Internet-Drafts may be updated, replaced, or obsoleted by | Internet community, and requests discussion and suggestions for | |||

other documents at any time. It is not appropriate to use Internet- | improvements. Please refer to the current edition of the "Internet | |||

Drafts as reference material or to cite them other than as a | Official Protocol Standards" (STD 1) for the standardization state | |||

``working draft'' or ``work in progress.'' | and status of this protocol. Distribution of this memo is unlimited. | |||

To view the entire list of current Internet-Drafts, please check the | Copyright Notice | |||

"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow | ||||

Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern | ||||

Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific | ||||

Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). | ||||

[Changes from the previous draft: change date, update author info, | Copyright (C) The Internet Society (1999). All Rights Reserved. | |||

add RFC 2119 reference] | ||||

Abstract | Abstract | |||

A standard method for storing RSA keys and and RSA/MD5 based | A standard method for storing RSA keys and and RSA/MD5 based | |||

signatures in the Domain Name System is described which utilizes DNS | signatures in the Domain Name System is described which utilizes DNS | |||

KEY and SIG resource records. | KEY and SIG resource records. | |||

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

Table of Contents | Table of Contents | |||

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

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

2. RSA Public KEY Resource Records.........................2 | ||||

Table of Contents..........................................2 | 3. RSA/MD5 SIG Resource Records............................2 | |||

4. Performance Considerations..............................3 | ||||

1. Introduction............................................3 | 5. Security Considerations.................................4 | |||

2. RSA Public KEY Resource Records.........................3 | References.................................................4 | |||

Author's Address...........................................5 | ||||

3. RSA/MD5 SIG Resource Records............................4 | Full Copyright Statement...................................6 | |||

4. Performance Considerations..............................5 | ||||

5. Security Considerations.................................5 | ||||

References.................................................6 | ||||

Author's Address...........................................6 | ||||

Expiration and File Name...................................6 | ||||

INTERNET-DRAFT RSA/MD5 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. The DNS has been extended to include digital | other information. The DNS has been extended to include digital | |||

signatures and cryptographic keys as described in [draft-ietf- | signatures and cryptographic keys as described in [RFC 2535]. Thus | |||

dnssec-secext2-*]. Thus the DNS can now be secured and used for | the DNS can now be secured and used for secure key distribution. | |||

secure key distribution. | ||||

This document describes how to store RSA keys and and RSA/MD5 based | This document describes how to store RSA keys and and RSA/MD5 based | |||

signatures in the DNS. Familiarity with the RSA algorithm is assumed | signatures in the DNS. Familiarity with the RSA algorithm is assumed | |||

[Schneier]. Implementation of the RSA algorithm in DNS is | [Schneier]. Implementation of the RSA algorithm in DNS is | |||

recommended. | recommended. | |||

The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" | The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" | |||

in this document are to be interpreted as described in RFC 2119. | in this document are to be interpreted as described in RFC 2119. | |||

2. RSA Public KEY Resource Records | 2. RSA Public KEY Resource Records | |||

RSA public keys are stored in the DNS as KEY RRs using algorithm | RSA public keys are stored in the DNS as KEY RRs using algorithm | |||

number 1 [draft-ietf-dnssec-secext2-*]. The structure of the | number 1 [RFC 2535]. The structure of the algorithm specific portion | |||

algorithm specific portion of the RDATA part of such RRs is as shown | of the RDATA part of such RRs is as shown below. | |||

below. | ||||

Field Size | Field Size | |||

----- ---- | ----- ---- | |||

exponent length 1 or 3 octets (see text) | exponent length 1 or 3 octets (see text) | |||

exponent as specified by length field | exponent as specified by length field | |||

modulus remaining space | modulus remaining space | |||

For interoperability, the exponent and modulus are each currently | For interoperability, the exponent and modulus are each currently | |||

limited to 4096 bits in length. The public key exponent is a | limited to 4096 bits in length. The public key exponent is a | |||

variable length unsigned integer. Its length in octets is | variable length unsigned integer. Its length in octets is | |||

represented as one octet if it is in the range of 1 to 255 and by a | represented as one octet if it is in the range of 1 to 255 and by a | |||

zero octet followed by a two octet unsigned length if it is longer | zero octet followed by a two octet unsigned length if it is longer | |||

than 255 bytes. The public key modulus field is a multiprecision | than 255 bytes. The public key modulus field is a multiprecision | |||

unsigned integer. The length of the modulus can be determined from | unsigned integer. The length of the modulus can be determined from | |||

the RDLENGTH and the preceding RDATA fields including the exponent. | the RDLENGTH and the preceding RDATA fields including the exponent. | |||

Leading zero octets are prohibited in the exponent and modulus. | Leading zero octets are prohibited in the exponent and modulus. | |||

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

3. RSA/MD5 SIG Resource Records | 3. RSA/MD5 SIG Resource Records | |||

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/MD5 algorithm, is calculated as shown below. The data signed is | RSA/MD5 algorithm, is calculated as shown below. The data signed is | |||

determined as specified in [draft-ietf-dnssec-secext2-*]. See | determined as specified in [RFC 2535]. See [RFC 2535] for fields in | |||

[draft-ietf-dnssec-secext2-*] for fields in the SIG RR RDATA which | the SIG RR RDATA which precede the signature itself. | |||

precede the signature itself. | ||||

hash = MD5 ( data ) | hash = MD5 ( data ) | |||

signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n) | signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) | |||

where MD5 is the message digest algorithm documented in [RFC 1321], | where MD5 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 MD5 algorithm designator prefix specified in PKCS1, | the ASN.1 BER MD5 algorithm designator prefix specified in [RFC | |||

that is, | 2437], that is, | |||

hex 3020300c06082a864886f70d020505000410 [NETSEC]. | hex 3020300c06082a864886f70d020505000410 [NETSEC]. | |||

This prefix is included to make it easier to use RSAREF (or similar | This prefix is included to make it easier to use RSAREF (or similar | |||

packages such as EuroRef). The FF octet MUST be repeated the maximum | packages such as EuroRef). 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 the same length in octets as 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 [PKCS1].) | Public Key Cryptographic Standard #1 [RFC 2437].) | |||

The size of n, including most and least significant bits (which will | 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 bits. n | 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 small. | and e SHOULD be chosen such that the public exponent is small. | |||

Leading zero bytes are permitted in the RSA/MD5 algorithm signature. | Leading zero bytes are permitted in the RSA/MD5 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 | |||

signature. Use of 3 as the public exponent is weak for | signature. Use of 3 as the public exponent is weak for | |||

confidentiality uses since, if the same data can be collected | confidentiality uses since, if the same data can be collected | |||

encrypted under three different keys with an exponent of 3 then, | encrypted under three different keys with an exponent of 3 then, | |||

using the Chinese Remainder Theorem [NETSEC], the original plain text | using the Chinese Remainder Theorem [NETSEC], the original plain text | |||

can be easily recovered. This weakness is not significant for DNS | can be easily recovered. This weakness is not significant for DNS | |||

security because we seek only authentication, not confidentiality. | security because we seek only authentication, not confidentiality. | |||

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

4. Performance Considerations | 4. Performance Considerations | |||

General signature generation speeds are roughly the same for RSA and | General signature generation speeds are roughly the same for RSA and | |||

DSA [RFC xDSA]. With sufficient pre-computation, signature | DSA [RFC 2536]. With sufficient pre-computation, signature | |||

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 overhead. While larger | typically less than 512 bytes including overhead. While larger | |||

transfers will perform correctly and work is underway to make larger | transfers will perform correctly and work is underway to make larger | |||

transfers more efficient, it is still advisable at this time to make | transfers more efficient, it is still advisable at this time to make | |||

reasonable efforts to minimize the size of KEY RR sets stored within | reasonable efforts to minimize the size of KEY RR sets stored within | |||

the DNS consistent with adequate security. Keep in mind that in a | the DNS consistent with adequate security. Keep in mind that in a | |||

secure zone, at least one authenticating SIG RR will also be | secure zone, at least one authenticating SIG RR will also be | |||

returned. | returned. | |||

5. Security Considerations | 5. Security Considerations | |||

Many of the general security consideration in [draft-ietf-dnssec- | Many of the general security consideration in [RFC 2535] apply. Keys | |||

secext2-*] apply. Keys retrieved from the DNS should not be trusted | retrieved from the DNS should not be trusted unless (1) they have | |||

unless (1) they have been securely obtained from a secure resolver or | been securely obtained from a secure resolver or independently | |||

independently verified by the user and (2) this secure resolver and | verified by the user and (2) this secure resolver and secure | |||

secure obtainment or independent verification conform to security | obtainment or independent verification conform to security policies | |||

policies acceptable to the user. As with all cryptographic | acceptable to the user. As with all cryptographic algorithms, | |||

algorithms, evaluating the necessary strength of the key is essential | evaluating the necessary strength of the key is essential and | |||

and dependent on local policy. | dependent on local policy. | |||

For interoperability, the RSA key size is limited to 4096 bits. For | For interoperability, the RSA key size is limited to 4096 bits. For | |||

particularly critical applications, implementors are encouraged to | particularly critical applications, implementors are encouraged to | |||

consider the range of available algorithms and key sizes. | consider the range of available algorithms and key sizes. | |||

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

References | References | |||

[NETSEC] - Network Security: PRIVATE Communications in a PUBLIC | [NETSEC] Kaufman, C., Perlman, R. and M. Speciner, "Network | |||

World, Charlie Kaufman, Radia Perlman, & Mike Speciner, Prentice Hall | Security: PRIVATE Communications in a PUBLIC World", | |||

Series in Computer Networking and Distributed Communications, 1995. | Series in Computer Networking and Distributed | |||

Communications, 1995. | ||||

[PKCS1] - PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., | [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography | |||

3 June 1991, Version 1.4. [there is an ID on this and any resulting | Specifications Version 2.0", RFC 2437, October 1998. | |||

RFC could be substitutes if available in time] | ||||

[RFC 1034] - P. Mockapetris, "Domain names - concepts and | [RFC 1034] Mockapetris, P., "Domain Names - Concepts and | |||

facilities", 11/01/1987. | Facilities", STD 13, RFC 1034, November 1987. | |||

[RFC 1035] - P. Mockapetris, "Domain names - implementation and | [RFC 1035] Mockapetris, P., "Domain Names - Implementation and | |||

specification", 11/01/1987. | Specification", STD 13, RFC 1035, November 1987. | |||

[RFC 1321] - R. Rivest, "The MD5 Message-Digest Algorithm", April | [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321 | |||

1992. | April 1992. | |||

[draft-ietf-dnssec-secext2-*] - Domain Name System Security | [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", | |||

Extensions, D. Eastlake, C. Kaufman, January 1997. | RFC 2535, March 1999. | |||

[RFC xDSA] - draft-ietf-dnssec-dss-*.txt | [RFC 2536] EastLake, D., "DSA KEYs and SIGs in the Domain Name | |||

System (DNS)", RFC 2536, March 1999. | ||||

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

Sons, ISBN 0-471-11709-9. | Wiley and Sons, ISBN 0-471-11709-9. | |||

Author's Address | Author's Address | |||

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

IBM | IBM | |||

318 Acton Street | 65 Shindegan Hill Road, RR #1 | |||

Carlisle, MA 01741 USA | Carmel, NY 10512 | |||

Telephone: +1-978-287-4877 | Phone: +1-914-276-2668(h) | |||

+1-914-784-7913 | +1-914-784-7913(w) | |||

FAX: +1-978-371-7148 | Fax: +1-914-784-3833(w) | |||

EMail: dee3@us.ibm.com | EMail: dee3@us.ibm.com | |||

Expiration and File Name | Full Copyright Statement | |||

This draft expires in April 1999. | Copyright (C) The Internet Society (1999). All Rights Reserved. | |||

Its file name is draft-ietf-dnssec-rsa-01.txt. | This document and translations of it may be copied and furnished to | |||

others, and derivative works that comment on or otherwise explain it | ||||

or assist in its implementation may be prepared, copied, published | ||||

and distributed, in whole or in part, without restriction of any | ||||

kind, provided that the above copyright notice and this paragraph are | ||||

included on all such copies and derivative works. However, this | ||||

document itself may not be modified in any way, such as by removing | ||||

the copyright notice or references to the Internet Society or other | ||||

Internet organizations, except as needed for the purpose of | ||||

developing Internet standards in which case the procedures for | ||||

copyrights defined in the Internet Standards process must be | ||||

followed, or as required to translate it into languages other than | ||||

English. | ||||

The limited permissions granted above are perpetual and will not be | ||||

revoked by the Internet Society or its successors or assigns. | ||||

This document and the information contained herein is provided on an | ||||

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | ||||

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | ||||

BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | ||||

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | ||||

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||

End of changes. 38 change blocks. | ||||

113 lines changed or deleted | | 76 lines changed or added | ||

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |