340 lines
11 KiB
Plaintext
340 lines
11 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group D. EastLake
|
||
Request for Comments: 2536 IBM
|
||
Category: Standards Track March 1999
|
||
|
||
|
||
DSA KEYs and SIGs 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 (1999). All Rights Reserved.
|
||
|
||
Abstract
|
||
|
||
A standard method for storing US Government Digital Signature
|
||
Algorithm keys and signatures in the Domain Name System is described
|
||
which utilizes DNS KEY and SIG resource records.
|
||
|
||
Table of Contents
|
||
|
||
Abstract...................................................1
|
||
1. Introduction............................................1
|
||
2. DSA KEY Resource Records................................2
|
||
3. DSA SIG Resource Records................................3
|
||
4. Performance Considerations..............................3
|
||
5. Security Considerations.................................4
|
||
6. IANA Considerations.....................................4
|
||
References.................................................5
|
||
Author's Address...........................................5
|
||
Full Copyright Statement...................................6
|
||
|
||
1. Introduction
|
||
|
||
The Domain Name System (DNS) is the global hierarchical replicated
|
||
distributed database system for Internet addressing, mail proxy, and
|
||
other information. The DNS has been extended to include digital
|
||
signatures and cryptographic keys as described in [RFC 2535]. Thus
|
||
the DNS can now be secured and can be used for secure key
|
||
distribution.
|
||
|
||
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 1]
|
||
|
||
RFC 2536 DSA in the DNS March 1999
|
||
|
||
|
||
This document describes how to store US Government Digital Signature
|
||
Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
|
||
US Digital Signature Algorithm is assumed [Schneier]. Implementation
|
||
of DSA is mandatory for DNS security.
|
||
|
||
2. DSA KEY Resource Records
|
||
|
||
DSA public keys are stored in the DNS as KEY RRs using algorithm
|
||
number 3 [RFC 2535]. The structure of the algorithm specific portion
|
||
of the RDATA part of this RR is as shown below. These fields, from Q
|
||
through Y are the "public key" part of the DSA KEY RR.
|
||
|
||
The period of key validity is not in the KEY RR but is indicated by
|
||
the SIG RR(s) which signs and authenticates the KEY RR(s) at that
|
||
domain name.
|
||
|
||
Field Size
|
||
----- ----
|
||
T 1 octet
|
||
Q 20 octets
|
||
P 64 + T*8 octets
|
||
G 64 + T*8 octets
|
||
Y 64 + T*8 octets
|
||
|
||
As described in [FIPS 186] and [Schneier]: T is a key size parameter
|
||
chosen such that 0 <= T <= 8. (The meaning for algorithm 3 if the T
|
||
octet is greater than 8 is reserved and the remainder of the RDATA
|
||
portion may have a different format in that case.) Q is a prime
|
||
number selected at key generation time such that 2**159 < Q < 2**160
|
||
so Q is always 20 octets long and, as with all other fields, is
|
||
stored in "big-endian" network order. P, G, and Y are calculated as
|
||
directed by the FIPS 186 key generation algorithm [Schneier]. P is
|
||
in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T
|
||
octets long. G and Y are quantities modulus P and so can be up to
|
||
the same length as P and are allocated fixed size fields with the
|
||
same number of octets as P.
|
||
|
||
During the key generation process, a random number X must be
|
||
generated such that 1 <= X <= Q-1. X is the private key and is used
|
||
in the final step of public key generation where Y is computed as
|
||
|
||
Y = G**X mod P
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 2]
|
||
|
||
RFC 2536 DSA in the DNS March 1999
|
||
|
||
|
||
3. DSA SIG Resource Records
|
||
|
||
The signature portion of the SIG RR RDATA area, when using the US
|
||
Digital Signature Algorithm, is shown below with fields in the order
|
||
they occur. See [RFC 2535] for fields in the SIG RR RDATA which
|
||
precede the signature itself.
|
||
|
||
Field Size
|
||
----- ----
|
||
T 1 octet
|
||
R 20 octets
|
||
S 20 octets
|
||
|
||
The data signed is determined as specified in [RFC 2535]. Then the
|
||
following steps are taken, as specified in [FIPS 186], where Q, P, G,
|
||
and Y are as specified in the public key [Schneier]:
|
||
|
||
hash = SHA-1 ( data )
|
||
|
||
Generate a random K such that 0 < K < Q.
|
||
|
||
R = ( G**K mod P ) mod Q
|
||
|
||
S = ( K**(-1) * (hash + X*R) ) mod Q
|
||
|
||
Since Q is 160 bits long, R and S can not be larger than 20 octets,
|
||
which is the space allocated.
|
||
|
||
T is copied from the public key. It is not logically necessary in
|
||
the SIG but is present so that values of T > 8 can more conveniently
|
||
be used as an escape for extended versions of DSA or other algorithms
|
||
as later specified.
|
||
|
||
4. Performance Considerations
|
||
|
||
General signature generation speeds are roughly the same for RSA [RFC
|
||
2537] and DSA. With sufficient pre-computation, signature generation
|
||
with DSA is faster than RSA. Key generation is also faster for DSA.
|
||
However, signature verification is an order of magnitude slower than
|
||
RSA when the RSA public exponent is chosen to be small as is
|
||
recommended for KEY RRs used in domain name system (DNS) data
|
||
authentication.
|
||
|
||
Current DNS implementations are optimized for small transfers,
|
||
typically less than 512 bytes including overhead. While larger
|
||
transfers will perform correctly and work is underway to make larger
|
||
transfers more efficient, it is still advisable at this time to make
|
||
reasonable efforts to minimize the size of KEY RR sets stored within
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 3]
|
||
|
||
RFC 2536 DSA in the DNS March 1999
|
||
|
||
|
||
the DNS consistent with adequate security. Keep in mind that in a
|
||
secure zone, at least one authenticating SIG RR will also be
|
||
returned.
|
||
|
||
5. Security Considerations
|
||
|
||
Many of the general security consideration in [RFC 2535] apply. Keys
|
||
retrieved from the DNS should not be trusted unless (1) they have
|
||
been securely obtained from a secure resolver or independently
|
||
verified by the user and (2) this secure resolver and secure
|
||
obtainment or independent verification conform to security policies
|
||
acceptable to the user. As with all cryptographic algorithms,
|
||
evaluating the necessary strength of the key is essential and
|
||
dependent on local policy.
|
||
|
||
The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
|
||
current DSA standard may limit the security of DSA. For particularly
|
||
critical applications, implementors are encouraged to consider the
|
||
range of available algorithms and key sizes.
|
||
|
||
DSA assumes the ability to frequently generate high quality random
|
||
numbers. See [RFC 1750] for guidance. DSA is designed so that if
|
||
manipulated rather than random numbers are used, very high bandwidth
|
||
covert channels are possible. See [Schneier] and more recent
|
||
research. The leakage of an entire DSA private key in only two DSA
|
||
signatures has been demonstrated. DSA provides security only if
|
||
trusted implementations, including trusted random number generation,
|
||
are used.
|
||
|
||
6. IANA Considerations
|
||
|
||
Allocation of meaning to values of the T parameter that are not
|
||
defined herein requires an IETF standards actions. It is intended
|
||
that values unallocated herein be used to cover future extensions of
|
||
the DSS standard.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 4]
|
||
|
||
RFC 2536 DSA in the DNS March 1999
|
||
|
||
|
||
References
|
||
|
||
[FIPS 186] U.S. Federal Information Processing Standard: Digital
|
||
Signature Standard.
|
||
|
||
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
|
||
Facilities", STD 13, RFC 1034, November 1987.
|
||
|
||
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
|
||
Specification", STD 13, RFC 1035, November 1987.
|
||
|
||
[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
|
||
Recommendations for Security", RFC 1750, December 1994.
|
||
|
||
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
|
||
RFC 2535, March 1999.
|
||
|
||
[RFC 2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
|
||
System (DNS)", RFC 2537, March 1999.
|
||
|
||
[Schneier] Schneier, B., "Applied Cryptography Second Edition:
|
||
protocols, algorithms, and source code in C", 1996.
|
||
|
||
Author's Address
|
||
|
||
Donald E. Eastlake 3rd
|
||
IBM
|
||
65 Shindegan Hill Road, RR #1
|
||
Carmel, NY 10512
|
||
|
||
Phone: +1-914-276-2668(h)
|
||
+1-914-784-7913(w)
|
||
Fax: +1-914-784-3833(w)
|
||
EMail: dee3@us.ibm.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 5]
|
||
|
||
RFC 2536 DSA in the DNS March 1999
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (1999). All Rights Reserved.
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eastlake Standards Track [Page 6]
|
||
|