As per Relevance of the word security, we have this rfc below:
Network Working Group D.
Request for Comments: 2536
Category: Standards Track March 1999
DSA KEYs and SIGs in the Domain Name System (DNS
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
A standard method for storing US Government Digital
Algorithm keys and signatures in the Domain Name System is
which utilizes DNS KEY and SIG resource records
Table of
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.
The Domain Name System (DNS) is the global hierarchical
distributed database system for Internet addressing, mail proxy,
other information. The DNS has been extended to include
signatures and cryptographic keys as described in [RFC 2535].
the DNS can now be secured and can be used for secure
distribution
Eastlake Standards Track [Page 1]
RFC 2536 DSA in the DNS March 1999
This document describes how to store US Government Digital
Algorithm (DSA) keys and signatures in the DNS. Familiarity with
US Digital Signature Algorithm is assumed [Schneier].
of DSA is mandatory for DNS security
2. DSA KEY Resource
DSA public keys are stored in the DNS as KEY RRs using
number 3 [RFC 2535]. The structure of the algorithm specific
of the RDATA part of this RR is as shown below. These fields, from
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
the SIG RR(s) which signs and authenticates the KEY RR(s) at
domain name
Field
----- ----
T 1
Q 20
P 64 + T*8
G 64 + T*8
Y 64 + T*8
As described in [FIPS 186] and [Schneier]: T is a key size
chosen such that 0 <= T <= 8. (The meaning for algorithm 3 if the
octet is greater than 8 is reserved and the remainder of the
portion may have a different format in that case.) Q is a
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,
stored in "big-endian" network order. P, G, and Y are calculated
directed by the FIPS 186 key generation algorithm [Schneier]. P
in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*
octets long. G and Y are quantities modulus P and so can be up
the same length as P and are allocated fixed size fields with
same number of octets as P
During the key generation process, a random number X must
generated such that 1 <= X <= Q-1. X is the private key and is
in the final step of public key generation where Y is computed
Y = G**X mod
Eastlake Standards Track [Page 2]
RFC 2536 DSA in the DNS March 1999
3. DSA SIG Resource
The signature portion of the SIG RR RDATA area, when using the
Digital Signature Algorithm, is shown below with fields in the
they occur. See [RFC 2535] for fields in the SIG RR RDATA
precede the signature itself
Field
----- ----
T 1
R 20
S 20
The data signed is determined as specified in [RFC 2535]. Then
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
S = ( K**(-1) * (hash + X*R) ) mod
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
the SIG but is present so that values of T > 8 can more
be used as an escape for extended versions of DSA or other
as later specified
4. Performance
General signature generation speeds are roughly the same for RSA [
2537] and DSA. With sufficient pre-computation, signature
with DSA is faster than RSA. Key generation is also faster for DSA
However, signature verification is an order of magnitude slower
RSA when the RSA public exponent is chosen to be small as
recommended for KEY RRs used in domain name system (DNS)
authentication
Current DNS implementations are optimized for small transfers
typically less than 512 bytes including overhead. While
transfers will perform correctly and work is underway to make
transfers more efficient, it is still advisable at this time to
reasonable efforts to minimize the size of KEY RR sets stored
Eastlake Standards Track [Page 3]
RFC 2536 DSA in the DNS March 1999
the DNS consistent with adequate security. Keep in mind that in
secure zone, at least one authenticating SIG RR will also
returned
5. Security
Many of the general security consideration in [RFC 2535] apply.
retrieved from the DNS should not be trusted unless (1) they
been securely obtained from a secure resolver or
verified by the user and (2) this secure resolver and
obtainment or independent verification conform to security
acceptable to the user. As with all cryptographic algorithms
evaluating the necessary strength of the key is essential
dependent on local policy
The key size limitation of a maximum of 1024 bits ( T = 8 ) in
current DSA standard may limit the security of DSA. For
critical applications, implementors are encouraged to consider
range of available algorithms and key sizes
DSA assumes the ability to frequently generate high quality
numbers. See [RFC 1750] for guidance. DSA is designed so that
manipulated rather than random numbers are used, very high
covert channels are possible. See [Schneier] and more
research. The leakage of an entire DSA private key in only two
signatures has been demonstrated. DSA provides security only
trusted implementations, including trusted random number generation
are used
6. IANA
Allocation of meaning to values of the T parameter that are
defined herein requires an IETF standards actions. It is
that values unallocated herein be used to cover future extensions
the DSS standard
Eastlake Standards Track [Page 4]
RFC 2536 DSA in the DNS March 1999
[FIPS 186] U.S. Federal Information Processing Standard:
Signature Standard
[RFC 1034] Mockapetris, P., "Domain Names - Concepts
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation
Specification", STD 13, RFC 1035, November 1987.
[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "
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
System (DNS)", RFC 2537, March 1999.
[Schneier] Schneier, B., "Applied Cryptography Second Edition
protocols, algorithms, and source code in C", 1996.
Author's
Donald E. Eastlake 3
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.
Eastlake Standards Track [Page 5]
RFC 2536 DSA in the DNS March 1999
Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Eastlake Standards Track [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
