mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-31 06:25:31 +00:00
Code Issues Releases Wiki Activity

new drafts

Browse Source
This commit is contained in:
Andreas Gustafsson
2001-07-13 01:50:43 +00:00
parent 699095b077
commit c0ce84c054
2 changed files with 1083 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

562
doc/draft/draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt Normal file
View File

@@ -0,0 +1,562 @@
Network Working Group R. Austein
draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt InterNetShare, Inc.
July 2001
Tradeoffs in DNS support for IPv6
Status of this document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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 months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>
The list of Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>
Distribution of this document is unlimited. Please send comments to
the Namedroppers mailing list <namedroppers@ops.ietf.org>.
Abstract
The IETF has two different proposals on the table for how to do DNS
support for IPv6, and has thus far failed to reach a clear consensus
on which approach is better. This note attempts to examine the pros
and cons of each approach, in the hope of clarifying the debate so
that we can reach closure and move on.
Introduction
RFC 1886 [Tweedledee] specified straightforward mechanisms to support
IPv6 addresses in the DNS. These mechanisms closely resemble the
mechanisms used to support IPv4, and with a minor improvement to the
reverse mapping mechanism based on experience with CIDR. RFC 1886 is
currently listed as a Proposed Standard.
Austein Expires 12 January 2002 [Page 1]
draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
RFC 2874 [Tweedledum] specified enhanced mechanisms to support IPv6
addresses in the DNS. These mechanisms provide new features that
make it possible for an IPv6 address stored in the DNS to be broken
up into multiple DNS resource records in ways that can reflect the
network topology underlying the address, thus making it possible for
the data stored in the DNS to reflect certain kinds of network
topology changes or routing architectures that are either impossible
or more difficult to represent without these mechanisms. RFC 2874 is
also currently listed as a Proposed Standard.
Both of these Proposed Standards were the output of the IPNG Working
Group. Both have been implemented, although implementation of
[Tweedledee] is more widespread, both because it was specified
earlier and because it's simpler to implement.
There's little question that the mechanisms proposed in [Tweedledum]
are more general than the mechanisms proposed in [Tweedledee], and
that these enhanced mechanisms might be valuable if IPv6's evolution
goes in certain directions. The questions are whether we really need
the more general mechanism, what new usage problems might come along
with the enhanced mechanisms, and what effect all this will have on
IPv6 deployment.
The one thing on which there does seem to be widespread agreement is
that we should make up our minds about all this Real Soon Now.
Main advantages of going with A6
While the A6 RR proposed in [Tweedledum] is very general and provides
a superset of the functionality provided by the AAAA RR in
[Tweedledee], many of the features of A6 can also be implemented with
AAAA RRs via preprocessing during zone file generation.
There is one specific area where A6 RRs provide something that cannot
be provided using AAAA RRs: A6 RRs can represent addresses in which a
prefix portion of the address can change without any action (or
perhaps even knowledge) by the parties controlling the DNS zone
containing the terminal portion (least significant bits) of the
address. This includes both so-called "rapid renumbering" scenarios
(where an entire network's prefix may change very quickly) and
routing architectures such as GSE (where the "routing goop" portion
of an address may be subject to change without warning). A6 RRs do
not completely remove the need to update leaf zones during all
renumbering events (for example, changing ISPs would usually require
a change to the upward delegation pointer), but careful use of A6 RRs
could keep the number of RRs that need to change during such an event
to a minimum.
Austein Expires 12 January 2002 [Page 2]
draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
Note that constructing AAAA RRs via preprocessing during zone file
generation requires exactly the sort of information that A6 RRs store
in the DNS. This begs the question of where the hypothetical
preprocessor obtains that information if it's not getting it from the
DNS.
Note also that the A6 RR, when restricted to its zero-length-prefix
form ("A6 0"), is semantically equivalent to an AAAA RR (with one
"wasted" octet in the wire representation), so anything that can be
done with an AAAA RR can also be done with an A6 RR.
Main advantages of going with AAAA
The AAAA RR proposed in [Tweedledee], while providing only a subset
of the functionality provided by the A6 RR proposed in [Tweedledum],
has two main points to recommend it:
- AAAA RRs are essentially identical (other than their length) to
IPv4's A RRs, so we have more than 15 years of experience to help
us predict the usage patterns, failure scenarios and so forth
associated with AAAA RRs.
- The AAAA RR is "optimized for read", in the sense that, by storing
a complete address rather than making the resolver fetch the
address in pieces, it minimizes the effort involved in fetching
addresses from the DNS (at the expense of increasing the effort
involved in injecting new data into the DNS).
Less compelling arguments in favor of A6
Since the A6 RR allows a zone administrator to write zone files whose
description of addresses maps to the underlying network topology, A6
RRs can be construed as a "better" way of representing addresses than
AAAA. This may well be a useful capability, but in and of itself
it's more of an argument for better tools for zone administrators to
use when constructing zone files than a justification for changing
the resolution protocol used on the wire.
Less compelling arguments in favor of AAAA
Some of the pressure to go with AAAA instead of A6 appears to be
based on the wider deployment of AAAA. Since it is possible to
construct transition tools (see discussion of AAAA synthesis, later
in this note), this does not appear to be a compelling argument if A6
provides features that we really need.
Another argument in favor of AAAA RRs over A6 RRs appears to be that
Austein Expires 12 January 2002 [Page 3]
draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
the A6 RR's advanced capabilities increase the number of ways in
which a zone administrator could build a non-working configuration.
While operational issues are certainly important, this is more of
argument that we need better tools for zone administrators than it is
a justification for turning away from A6 if A6 provides features that
we really need.
Potential problems with A6
The enhanced capabilities of the A6 RR, while interesting, are not in
themselves justification for choosing A6 if we don't really need
those capabilities. The A6 RR is "optimized for write", in the sense
that, by making it possible to store fragmented IPv6 addresses in the
DNS, it makes it possible to reduce the effort that it takes to
inject new data into the DNS (at the expense of increasing the effort
involved in fetching data from the DNS). This may be justified if we
expect the effort involved in maintaining AAAA-style DNS entries to
be prohibitive, but in general, we expect the DNS data to be read
more frequently than it is written, so we need to evaluate this
particular tradeoff very carefully.
There are also several potential issues with A6 RRs that stem
directly from the feature that makes them different from AAAA RRs:
the ability to build up address via chaining.
Resolving a chain of A6 RRs involves resolving a series of what are
almost independent queries, but not quite. Each of these sub-queries
takes some non-zero amount of time, unless the answer happens to be
in the resolver's local cache already. Assuming that resolving an
AAAA RR takes time T as a baseline, we can guess that, on the
average, it will take something approaching time N*T to resolve an N-
link chain of A6 RRs, although we would expect to see a fairly good
caching factor for the A6 fragments representing the more significant
bits of an address. This leaves us with two choices, neither of
which is very good: we can decrease the amount of time that the
resolver is willing to wait for each fragment, or we can increase the
amount of time that a resolver is willing to wait before returning
failure to a client. What little data we have on this subject
suggests that users are already impatient with the length of time it
takes to resolve A RRs in the IPv4 Internet, which suggests that they
are not likely to be patient with significantly longer delays in the
IPv6 Internet. At the same time, terminating queries prematurely is
both a waste of resources and another source of user frustration.
Thus, we are forced to conclude that indiscriminate use of long A6
chains is likely to lead to problems.
To make matters worse, the places where A6 RRs are likely to be most
critical for rapid renumbering or GSE-like routing are situations
Austein Expires 12 January 2002 [Page 4]
draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
where the prefix name field in the A6 RR points to a target that is
not only outside the DNS zone containing the A6 RR, but is
administered by a different organization (for example, in the case of
an end user's site, the prefix name will most likely point to a name
belonging to an ISP that provides connectivity for the site). While
pointers out of zone are not a problem per se, pointers to other
organizations are somewhat more difficult to maintain and less
susceptible to automation than pointers within a single organization
would be. Experience both with glue RRs and with PTR RRs in the IN-
ADDR.ARPA tree suggests that many zone administrators do not really
understand how to set up and maintain these pointers properly, and we
have no particular reason to believe that these zone administrators
will do a better job with A6 chains than they do today. To be fair,
however, the alternative case of building AAAA RRs via preprocessing
before loading zones has many of the same problems; at best, one can
claim that using AAAA RRs for this purpose would allow DNS clients to
get the wrong answer somewhat more efficiently than with A6 RRs.
Finally, assuming near total ignorance of how likely a query is to
fail, the probability of failure with an N-link A6 chain would appear
to be roughly proportional to N, since each of the queries involved
in resolving an A6 chain would have the same probability of failure
as a single AAAA query. Note again that this comment applies to
failures in the the process of resolving a query, not to the data
obtained via that process. Arguably, in an ideal world, A6 RRs would
increase the probability of the answer a client (finally) gets being
right, assuming that nothing goes wrong in the query process, but we
have no real idea how to quantify that assumption at this point even
to the hand-wavey extent used elsewhere in this note.
One potential problem that has been raised in the past regarding A6
RRs turns out not to be a serious issue. The A6 design includes the
possibility of there being more than one A6 RR matching the prefix
name portion of a leaf A6 RR. That is, an A6 chain may not be a
simple linked list, it may in fact be a tree, where each branch
represents a possible prefix. Some critics of A6 have been concerned
that this will lead to a wild expansion of queries, but this turns
out not to be a problem if a resolver simply follows the "bounded
work per query" rule described in RFC 1034 (page 35). That rule
applies to all work resulting from attempts to process a query,
regardless of whether it's a simple query, a CNAME chain, an A6 tree,
or an infinite loop. The client may not get back a useful answer in
cases where the zone has been configured badly, but a proper
implementation should not produce a query explosion as a result of
processing even the most perverse A6 tree, chain, or loop.
Austein Expires 12 January 2002 [Page 5]
draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
Interactions with DNSSEC
One of the areas where AAAA and A6 RRs differ is in the precise
details of how they interact with DNSSEC. The following comments
apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are
semantically equivalent to AAAA RRs).
Other things being equal, the time it takes to re-sign all of the
addresses in a zone after a renumbering event is longer with AAAA RRs
than with A6 RRs (because each address record has to be re-signed
rather than just signing a common prefix A6 RR and a few A6 0 RRs
associated with the zone's name servers). Note, however, that in
general this does not present a serious scaling problem, because the
re-signing is performed in the leaf zones.
Other things being equal, there's more work involved in verifying the
signatures received back for A6 RRs, because each address fragment
has a separate associated signature. Similarly, a DNS message
containing a set of A6 address fragments and their associated
signatures will be larger than the equivalent packet with a single
AAAA (or A6 0) and a single associated signature.
Since AAAA RRs cannot really represent rapid renumbering or GSE-style
routing scenarios very well, it should not be surprising that DNSSEC
signatures of AAAA RRs are also somewhat problematic. In cases where
the AAAA RRs would have to be changing very quickly to keep up with
prefix changes, the time required to re-sign the AAAA RRs may be
prohibitive.
Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that
333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the
BIND-9 dnssec-signzone program under NetBSD can generate roughly 40
1024-bit RSA signatures per second. Extrapolating from this,
assuming one A RR, one AAAA RR, and one NXT RR per host, this
suggests that it would take this laptop a few hours to sign a zone
listing 10**5 hosts, or about a day to sign a zone listing 10**6
hosts using AAAA RRs.
This suggests that the additional effort of re-signing a large zone
full of AAAA RRs during a re-numbering event, while noticeable, is
only likely to be prohibitive in the rapid renumbering case where
AAAA RRs don't work well anyway.
Interactions with dynamic update
DNS dynamic update appears to work equally well for AAAA or A6 RRs,
with one minor exception: with A6 RRs, the dynamic update client
needs to know the prefix length and prefix name. At present, no
Austein Expires 12 January 2002 [Page 6]
draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
mechanism exists to inform a dynamic update client of these values,
but presumably such a mechanism could be provided via an extension to
DHCP, or some other equivalent could be devised.
Transition from AAAA to A6 via AAAA synthesis
While AAAA is at present more widely deployed than A6, it is possible
to transition from AAAA-aware DNS software to A6-aware DNS software.
A rough plan for this was presented at IETF-50 in Minneapolis and has
been discussed on the ipng mailing list. So if the IETF concludes
that A6's enhanced capabilities are necessary, it should be possible
to transition from AAAA to A6.
The details of this transition have been left to a separate document,
but the general idea is that the resolver that is performing
iterative resolution on behalf of a DNS client program could
synthesize AAAA RRs representing the result of performing the
equivalent A6 queries. Note that in this case it is not possible to
generate an equivalent DNSSEC signature for the AAAA RR, so clients
that care about performing DNSSEC validation for themselves would
have to issue A6 queries directly rather than relying on AAAA
synthesis.
Bitlabels
While the differences between AAAA and A6 RRs have generated most of
the discussion to date, there are also two proposed mechanisms for
building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-
ADDR.ARPA tree).
[Tweedledee] proposes a mechanism very similar to the IN-ADDR.ARPA
mechanism used for IPv4 addresses: the RR name is the hexadecimal
representation of the IPv6 address, reversed and concatenated with a
well-known suffix, broken up with a dot between each hexadecimal
digit. The resulting DNS names are somewhat tedious for humans to
type, but are very easy for programs to generate. Making each
hexadecimal digit a separate label means that delegation on arbitrary
bit boundaries will result in a maximum of 16 NS RRs per label;
again, the mechanism is somewhat tedious for humans, but is very easy
to program. As with IPv4's IN-ADDR.ARPA tree, the one place where
this scheme is weak is in handling delegations in the least
significant label; however, since there appears to be no real need to
delegate the least significant four bits of an IPv6 address, this
does not appear to be a serious restriction.
[Tweedledum] proposed a radically different way of naming entries in
the reverse mapping tree: rather than using textual representations
of addresses, it proposes to use a new kind of DNS label (a "bit
Austein Expires 12 January 2002 [Page 7]
draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
label") to represent binary addresses directly in the DNS. This has
the advantage of being significantly more compact than the textual
representation, and arguably might have been a better solution for
DNS to use for this purpose if it had been designed into the protocol
from the outset. Unfortunately, experience to date suggests that
deploying a new DNS label type is very hard: all of the DNS name
servers that are authoritative for any portion of the name in
question must be upgraded before the new label type can be used, as
must any resolvers involved in the resolution process. Any name
server that has not been upgraded to understand the new label type
will reject the query as being malformed.
Since the main benefit of the bit label approach appears to be an
ability that we don't really need (delegation in the least
significant four bits of an IPv6 address), and since the upgrade
problem is likely to render bit labels unusable until a significant
portion of the DNS code base has been upgraded, it is difficult to
escape the conclusion that the textual solution is good enough.
DNAME RRs
[Tweedledum] also proposes using DNAME RRs as a way of providing the
equivalent of A6's fragmented addresses in the reverse mapping tree.
That is, by using DNAME RRs, one can write zone files for the reverse
mapping tree that have the same ability to cope with rapid
renumbering or GSE-style routing that the A6 RR offers in the main
portion of the DNS tree. Consequently, the need to use DNAME in the
reverse mapping tree appears to be closely tied to the need to use
fragmented A6 in the main tree: if one is necessary, so is the other,
and if one isn't necessary, the other isn't either.
Other uses have also been proposed for the DNAME RR, but since they
are outside the scope of the IPv6 address discussion, they will not
be addressed here.
Other topics ???
Recommendation
Distilling the above feature comparisons down to their key elements,
the important questions appear to be:
(a) Is IPv6 going to do rapid renumber or GSE-like routing?
(b) Is the reverse mapping tree for IPv6 going to require delegation
in the least significant four bits of the address?
Question (a) appears to be the key to the debate. This is really a
decision for the IPv6 community to make, not the DNS community.
Austein Expires 12 January 2002 [Page 8]
draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
Question (b) is also for the IPv6 community to make, but it seems
fairly obvious that the answer is "no".
Recommendations based on these questions:
(1) If the IPv6 working groups seriously intend to specify and deploy
rapid renumbering or GSE-like routing, we should transition to
using the A6 RR in the main tree and to using DNAME RRs as
necessary in the reverse tree.
(2) Otherwise, we should keep the simpler AAAA solution in the main
tree and should not use DNAME RRs in the reverse tree.
(3) In either case, the reverse tree should use the textual
representation described in [Tweedledee] rather than the bit
label representation described in [Tweedledum].
(4) If we do go to using A6 RRs in the main tree and to using DNAME
RRs in the reverse tree, we should write applicability statements
and implementation guidelines designed to discourage excessively
complex uses of these features; in general, any network that can
be described adequately using A6 0 RRs and without using DNAME
RRs should be described that way, and the enhanced features
should be used only when absolutely necessary, at least until we
have much more experience with them and have a better
understanding of their failure modes.
Security Considerations
???
IANA Considerations
None, since all of these RR types have already been allocated.
Acknowledgments
This note is based on a number of discussions both public and private
over a period of (at least) eight years, but particular thanks go to
Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun
Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush,
and Sue Thomson, none of whom are responsible for what the author did
with their ideas.
References
[Tweedledee] Thomson, S., and Huitema, C., "DNS Extensions to support
IP version 6", RFC 1886, December 1995.
[Tweedledum] Crawford, M., and Huitema, C., "DNS Extensions to
Support IPv6 Address Aggregation and Renumbering" RFC 2874, July
Austein Expires 12 January 2002 [Page 9]
draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
2000.
[Sommerfeld] Private message to the author from Bill Sommerfeld dated
21 March 2001, summarizing the result of experiments he
performed on a copy of the MIT.EDU zone.
Author's addresses:
Rob Austein
InterNetShare, Inc.
505 West Olive Ave., Suite 321
Sunnyvale, CA 94086
USA
sra@hactrn.net
Austein Expires 12 January 2002 [Page 10]

521
doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-00.txt Normal file
View File

@@ -0,0 +1,521 @@
INTERNET-DRAFT Diffie-Hellman Keys in the DNS
OBSOLETES: RFC 2539 Donald Eastlake 3rd
Motorola
Expires: January 2002 July 2001
Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
------- -- -------------- ---- -- --- ------ ---- ------ -----
<draft-ietf-dnsext-rfc2539bis-dhk-00.txt>
Donald E. Eastlake 3rd
Status of This Document
This draft is intended to be become a Draft Standard RFC.
Distribution of this document is unlimited. Comments should be sent
to the DNS extensions working group mailing list
<namedroppers@ops.ietf.org> or to the author.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. 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 months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Donald Eastlake 3rd [Page 1]
INTERNET-DRAFT Diffie-Hellman Keys in the DNS
Abstract
A standard method for storing Diffie-Hellman keys in the Domain Name
System is described which utilizes DNS KEY resource records.
Acknowledgements
Part of the format for Diffie-Hellman keys and the description
thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
and Hemma Prafullchandra.
In addition, the following persons provided useful comments that were
incorporated into the predecessor of this document: Ran Atkinson,
Thomas Narten.
Donald Eastlake 3rd [Page 2]
INTERNET-DRAFT Diffie-Hellman Keys in the DNS
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Acknowledgements...........................................2
Table of Contents..........................................3
1. Introduction............................................4
1.1 About This Document....................................4
1.2 About Diffie-Hellman...................................4
2. Diffie-Hellman KEY Resource Records.....................5
3. Performance Considerations..............................6
4. IANA Considerations.....................................6
5. Security Considerations.................................6
References.................................................7
Author's Address...........................................7
Expiration and File Name...................................7
Appendix A: Well known prime/generator pairs...............8
A.1. Well-Known Group 1: A 768 bit prime..................8
A.2. Well-Known Group 2: A 1024 bit prime.................8
A.3. Well-Known Group 3: A 1536 bit prime.................9
Donald Eastlake 3rd [Page 3]
INTERNET-DRAFT Diffie-Hellman Keys in the DNS
1. Introduction
The Domain Name System (DNS) is the current global hierarchical
replicated distributed database system for Internet addressing, mail
proxy, and similar information. The DNS has been extended to include
digital signatures and cryptographic keys as described in [RFC 2535].
Thus the DNS can now be used for secure key distribution.
1.1 About This Document
This document describes how to store Diffie-Hellman keys in the DNS.
Familiarity with the Diffie-Hellman key exchange algorithm is assumed
[Schneier].
1.2 About Diffie-Hellman
Diffie-Hellman requires two parties to interact to derive keying
information which can then be used for authentication. Since DNS SIG
RRs are primarily used as stored authenticators of zone information
for many different resolvers, no Diffie-Hellman algorithm SIG RR is
defined. For example, assume that two parties have local secrets "i"
and "j". Assume they each respectively calculate X and Y as follows:
X = g**i ( mod p )
Y = g**j ( mod p )
They exchange these quantities and then each calculates a Z as
follows:
Zi = Y**i ( mod p )
Zj = X**j ( mod p )
Zi and Zj will both be equal to g**(ij)(mod p) and will be a shared
secret between the two parties that an adversary who does not know i
or j will not be able to learn from the exchanged messages (unless
the adversary can derive i or j by performing a discrete logarithm
mod p which is hard for strong p and g).
The private key for each party is their secret i (or j). The public
key is the pair p and g, which must be the same for the parties, and
their individual X (or Y).
For further information about Diffie-Hellman and precautions to take
in deciding on a p and g, see [RFC 2631].
Donald Eastlake 3rd [Page 4]
INTERNET-DRAFT Diffie-Hellman Keys in the DNS
2. Diffie-Hellman KEY Resource Records
Diffie-Hellman keys are stored in the DNS as KEY RRs using algorithm
number 2. The structure of the RDATA portion of this RR is as shown
below. The first 4 octets, including the flags, protocol, and
algorithm fields are common to all KEY RRs as described in [RFC
2535]. The remainder, from prime length through public value is the
"public key" part of the 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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEY flags | protocol | algorithm=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prime length (or flag) | prime (p) (or special) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ prime (p) (variable length) | generator length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| generator (g) (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| public value length | public value (variable length)/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 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
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
Appedix A for defined table entries and Section 4 for information on
allocating additional table entries. The meaning of a zero or 3
through 15 value for "prime length" is reserved.
Generator length is the length of the generator (g) in bytes.
Generator is the binary representation of generator with most
significant byte first. PublicValueLen is the Length of the Public
Value (g**i (mod p)) in bytes. PublicValue is the binary
representation of the DH public value with most significant byte
first.
The corresponding algorithm=2 SIG resource record is not used so no
format for it is defined.
Donald Eastlake 3rd [Page 5]
INTERNET-DRAFT Diffie-Hellman Keys in the DNS
3. Performance Considerations
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
minimize the size of KEY RR sets stored within the DNS consistent
with adequate security. Keep in mind that in a secure zone, at least
one authenticating SIG RR will also be returned.
4. IANA Considerations
Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
an IETF consensus as defined in [RFC 2434].
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 proposes to assign 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.
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 important and
dependent on local policy.
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]
Donald Eastlake 3rd [Page 6]
INTERNET-DRAFT Diffie-Hellman Keys in the DNS
References
[RFC 1034] - P. Mockapetris, "Domain names - concepts and
facilities", November 1987.
[RFC 1035] - P. Mockapetris, "Domain names - implementation and
specification", November 1987.
[RFC 2434] - Guidelines for Writing an IANA Considerations Section in
RFCs, T. Narten, H. Alvestrand, October 1998.
[RFC 2535] - Domain Name System Security Extensions, D. Eastlake 3rd,
March 1999.
[RFC 2539] - Storage of Diffie-Hellman Keys in the Domain Name System
(DNS), D. Eastlake, March 1999, obsoleted by this RFC.
[RFC 2631] - Diffie-Hellman Key Agreement Method, E. Rescorla, June
1999.
[RFC 2671] - Extension Mechanisms for DNS (EDNS0), P. Vixie, August
1999.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons.
Author's Address
Donald E. Eastlake 3rd
Motorola
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1-508-261-5434 (w)
+1-508-634-2066 (h)
FAX: +1-508-261-4447 (w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in January 2002.
Its file name is draft-ietf-dnsext-rfc2539bis-dhk-00.txt.
Donald Eastlake 3rd [Page 7]
INTERNET-DRAFT Diffie-Hellman Keys in the DNS
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.
Richard Schroeppel performed all the mathematical and computational
work for this appendix.
A.1. Well-Known Group 1: A 768 bit prime
The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
decimal value is
155251809230070893513091813125848175563133404943451431320235
119490296623994910210725866945387659164244291000768028886422
915080371891804634263272761303128298374438082089019628850917
0691316593175367469551763119843371637221007210577919
Prime modulus: Length (32 bit words): 24, Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
Generator: Length (32 bit words): 1, Data (hex): 2
A.2. Well-Known Group 2: A 1024 bit prime
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its decimal value is
179769313486231590770839156793787453197860296048756011706444
423684197180216158519368947833795864925541502180565485980503
646440548199239100050792877003355816639229553136239076508735
759914822574862575007425302077447712589550957937778424442426
617334727629299387668709205606050270810842907692932019128194
467627007
Prime modulus: Length (32 bit words): 32, Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF
Generator: Length (32 bit words): 1, Data (hex): 2
Donald Eastlake 3rd [Page 8]
INTERNET-DRAFT Diffie-Hellman Keys in the DNS
A.3. Well-Known Group 3: A 1536 bit prime
The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
Its decimal value is
241031242692103258855207602219756607485695054850245994265411
694195810883168261222889009385826134161467322714147790401219
650364895705058263194273070680500922306273474534107340669624
601458936165977404102716924945320037872943417032584377865919
814376319377685986952408894019557734611984354530154704374720
774996976375008430892633929555996888245787241299381012913029
459299994792636526405928464720973038494721168143446471443848
8520940127459844288859336526896320919633919
Prime modulus Length (32 bit words): 48, Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
Generator: Length (32 bit words): 1, Data (hex): 2
Donald Eastlake 3rd [Page 9]