summaryrefslogtreecommitdiffstats
path: root/doc/rfc/rfc2536.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2536.txt')
-rw-r--r--doc/rfc/rfc2536.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc2536.txt b/doc/rfc/rfc2536.txt
new file mode 100644
index 0000000..88be242
--- /dev/null
+++ b/doc/rfc/rfc2536.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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]
+
generated by cgit (git 2.34.1) at 2024-04-18 15:45:39 +0000