+
INTERNET-DRAFT DSA Information in the DNS
OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
Motorola Laboratories
-Expires: February 2005 August 2004
+Expires: September 2005 March 2005
DSA Keying and Signature Information in the DNS
--- ------ --- --------- ----------- -- --- ---
- <draft-ietf-dnsext-rfc2536bis-dsa-04.txt>
+ <draft-ietf-dnsext-rfc2536bis-dsa-05.txt>
Donald E. Eastlake 3rd
Copyright Notice
- Copyright (C) The Internet Society 2004. All Rights Reserved.
+ Copyright (C) The Internet Society 2005. All Rights Reserved.
+
2. DSA Keying Information
When DSA public keys are stored in the DNS, the structure of the
- relevant part of the RDATA part of the RR being used is as shown
- below.
+ relevant part of the RDATA part of the RR being used is the fields
+ listed below in the order given.
The period of key validity is not included in this data but is
- indicated separately, for example by an RR which signs and
- authenticates the RR containing the keying information.
+ indicated separately, for example by an RR such as RRSIG which signs
+ and authenticates the RR containing the keying information.
Field Size
----- ----
parameter chosen such that 0 <= T <= 8. (The meaning if the T octet
is greater than 8 is reserved and the remainder of the data 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-2] key generation algorithm [Schneier]. P is in the range
+ key generation time such that 2**159 < Q < 2**160. Thus 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-2] key generation algorithm [Schneier]. P is in the range
2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G
and Y are quantities modulo P and so can be up to the same length as
P and are allocated fixed size fields with the same number of octets
The portion of the RDATA area used for US Digital Signature Algorithm
signature information is shown below with fields in the order they
- occur.
+ are listed and the contents of each multi-octet field in "big-endian"
+ network order.
Field Size
----- ----
R 20 octets
S 20 octets
- The data signed must be determined. Then the following steps are
- taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
+ First, the data signed must be determined. Then the following steps
+ are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
specified in the public key [Schneier]:
hash = SHA-1 ( data )
S = ( K**(-1) * (hash + X*R) ) mod Q
- For infromation on the SHA-1 hash function see [FIPS 180-1] and [RFC
+ For information on the SHA-1 hash function see [FIPS 180-1] and [RFC
3174].
Since Q is 160 bits long, R and S can not be larger than 20 octets,
recommended for some applications.
-
D. Eastlake 3rd [Page 4]
\f
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
+ numbers. See [random] for guidance. DSA is designed so that if
biased rather than random numbers are used, 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
Copyright and Disclaimer
- Copyright (C) The Internet Society 2004. This document is subject to
+ Copyright (C) The Internet Society 2005. This document is subject to
the rights, licenses and restrictions contained in BCP 78 and except
as set forth therein, the authors retain all their rights.
Informative References
+ [random] - "Randomness Recommendations for Security", D. Eastlake, S.
+ Crocker, J. Schiller, work in progress, draft-eastlake-
+ randomness2-*.txt currently in RFC Editor's queue.
+
[RFC 1034] - "Domain names - concepts and facilities", P.
Mockapetris, 11/01/1987.
[RFC 1035] - "Domain names - implementation and specification", P.
Mockapetris, 11/01/1987.
- [RFC 1750] - "Randomness Recommendations for Security", D. Eastlake,
- S. Crocker, J. Schiller, December 1994.
-
[RFC intro] - "DNS Security Introduction and Requirements", R.
Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress,
draft-ietf-dnsext-dnssec-intro-*.txt.
-
D. Eastlake 3rd [Page 7]
\f
Milford, MA 01757 USA
Telephone: +1-508-786-7554(w)
- +1-508-634-2066(h)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
- This draft expires in February 2005.
+ This draft expires in September 2005.
+
+ Its file name is draft-ietf-dnsext-rfc2536bis-dsa-05.txt.
- Its file name is draft-ietf-dnsext-rfc2536bis-dsa-04.txt.
-
INTERNET-DRAFT Diffie-Hellman Information in the DNS
OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
Motorola Laboratories
-Expires: February 2005 August 2004
+Expires: September 2005 March 2005
Storage of Diffie-Hellman Keying Information in the DNS
------- -- -------------- ------ ----------- -- --- ---
- <draft-ietf-dnsext-rfc2539bis-dhk-04.txt>
+ <draft-ietf-dnsext-rfc2539bis-dhk-05.txt>
Copyright
- Copyright (C) The Internet Society 2004.
+ Copyright (C) The Internet Society 2005.
they are encoded as shown below.
The period of key validity is not included in this data but is
- indicated separately, for example by an RR which signs and
- authenticates the RR containing the keying information.
+ indicated separately, for example by an RR such as RRSIG which signs
+ and authenticates the RR containing the keying information.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
/ public value (g^i mod p) (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Prime length is length of the Diffie-Hellman prime (p) in bytes if it
- is 16 or greater. Prime contains the binary representation of the
- Diffie-Hellman prime with most significant byte first (i.e., in
+ Prime length is the length of the Diffie-Hellman prime (p) in bytes
+ if it is 16 or greater. Prime contains the binary representation of
+ the Diffie-Hellman prime with most significant byte first (i.e., in
network order). If "prime length" field is 1 or 2, then the "prime"
field is actually an unsigned index into a table of 65,536
prime/generator pairs and the generator length SHOULD be zero. See
Current DNS implementations are optimized for small transfers,
typically less than 512 bytes including DNS overhead. Larger
transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient, it
- is still advisable at this time to make reasonable efforts to
+ standardized [RFC 2671] to make larger transfers more efficient. But
+ it is still advisable at this time to make reasonable efforts to
minimize the size of RR sets containing keying information consistent
with adequate security.
Well known prime/generator pairs number 0x0000 through 0x07FF can
only be assigned by an IETF standards action. [RFC 2539], the
Proposed Standard predecessor of this document, assigned 0x0001
- through 0x0002. This document assigns 0x0003. Pairs number 0s0800
- through 0xBFFF can be assigned based on RFC documentation. Pairs
- number 0xC000 through 0xFFFF are available for private use and are
- not centrally coordinated. Use of such private pairs outside of a
- closed environment may result in conflicts and/or security failures.
+ through 0x0002. This document additionally assigns 0x0003. Pairs
+ number 0s0800 through 0xBFFF can be assigned based on RFC
+ documentation. Pairs number 0xC000 through 0xFFFF are available for
+ private use and are not centrally coordinated. Use of such private
+ pairs outside of a closed environment may result in conflicts and/or
+ security failures.
In addition, the usual Diffie-Hellman key strength considerations
apply. (p-1)/2 should also be prime, g should be primitive mod p, p
- should be "large", etc. [RFC 2631, Schneier]
+ should be "large", etc. See [RFC 2631, Schneier].
Copyright and Disclaimer
- Copyright (C) The Internet Society 2004. This document is subject to
+ Copyright (C) The Internet Society 2005. This document is subject to
the rights, licenses and restrictions contained in BCP 78 and except
as set forth therein, the authors retain all their rights.
-
D. Eastlake 3rd [Page 5]
\f
155 Beaver Street
Milford, MA 01757 USA
- Telephone: +1-508-786-7554 (w)
+ Telephone: +1-508-786-7554
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT Diffie-Hellman Information in the DNS
- +1-508-634-2066 (h)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
- This draft expires in February 2005.
+ This draft expires in September 2005.
+
+ Its file name is draft-ietf-dnsext-rfc2539bis-dhk-05.txt.
- Its file name is draft-ietf-dnsext-rfc2539bis-dhk-04.txt.
Appendix A: Well known prime/generator pairs
These numbers are copied from the IPSEC effort where the derivation of
- these values is more fully explained and additional information is available.
+ these values is more fully explained and additional information is
+ available.
Richard Schroeppel performed all the mathematical and computational
work for this appendix.
-
D. Eastlake 3rd [Page 9]
\f
projects / thirdparty / bind9.git / commitdiff
