441 lines
19 KiB
Plaintext
441 lines
19 KiB
Plaintext
|
|
DNSIND WG Edward Lewis
|
|
INTERNET DRAFT TIS Labs
|
|
May Update: RFC 2535 Jerry Scharf
|
|
Catagory: I-D ISC
|
|
April 1, 1999
|
|
|
|
The Zone Key Referral
|
|
<draft-ietf-dnsind-keyreferral-00.txt>
|
|
|
|
Status of this Memo
|
|
|
|
This document is an Internet-Draft and is in full conformance with
|
|
all provisions of Section 10 of RFC2026.
|
|
|
|
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.
|
|
|
|
Comments should be sent to the authors or the DNSIND WG mailing list
|
|
<namedroppers@internic.net>.
|
|
|
|
This draft expires on October 1, 1999
|
|
|
|
Copyright Notice
|
|
|
|
Copyright (C) The Internet Society (1999). All rights
|
|
reserved.
|
|
|
|
Notes on this document
|
|
|
|
This section will only appear in the -00.txt edition of this draft.
|
|
|
|
This document originated in the DNSSEC working group in June 1998. The
|
|
discussion of the issues in this draft were tabled until the publication
|
|
of the then current DNSSEC drafts as RFCs.
|
|
|
|
The first version of this document lists a third author, John Gilmore.
|
|
He is listed as an author because he was one of the initiators of what is
|
|
proposed. In this and following versions he is only listed in the
|
|
Acknowledgements (as opposed to being an author) as he has not been
|
|
involved in the writing/editing of the draft. This has been done to
|
|
avoid assigning his name to a document he may not have a chance to read,
|
|
this is not intended as a slight on his efforts.
|
|
|
|
When commenting on this draft, please be aware that some terms used here
|
|
are up for negotiation before progressing - such as "thief" and "road
|
|
block" appearing later in the draft. Comments which are left justified
|
|
were added during the re-issuing of the draft, they add context that
|
|
may have been lost over time.
|
|
|
|
Abstract
|
|
|
|
A new type of key is defined to address the problems of
|
|
performance in large delegeted zones and issues of liability of
|
|
registrars with regards to the storing of public keys belonging
|
|
to zone cuts. This new key type also brings DNSSEC more in line
|
|
with the DNS treatment of zone cuts and speeds recovery in
|
|
handling privatekey exposure.
|
|
|
|
The new type of key is a referral record that is stored, signed,
|
|
at the parent zone's place for the delegation point. A resolver
|
|
receiving this record is being informed that there are genuine
|
|
public keys at the child's authoritative name servers. The
|
|
parent no longer needs to store the child's public keys locally.
|
|
|
|
1 Introduction
|
|
|
|
There are a number of different reasons for the proposal of this
|
|
new key type. Reasons include:
|
|
o the performance impact that RFC 2535 has on name servers
|
|
o the problem of updating a widely delegated parent zone on demand
|
|
o statements in RFC 2181 on authoritative data at delegations
|
|
o perceived liability of the operator of a name server or registry
|
|
|
|
To address these issues, which are expanded upon below, a new
|
|
key type is proposed - a "zone key referral" - to join the user
|
|
key, host key, and zone key types defined in RFC 2535.
|
|
|
|
1.1 Performance Issues
|
|
|
|
A sample zone will be used to illustrate the problem. The
|
|
example will part from reality mostly in the length of zone
|
|
names, which changes the size of the owner and resource record
|
|
data fields.
|
|
|
|
# $ORIGIN test.
|
|
# @ IN SOA <SOA data>
|
|
# IN SIG SOA <by test.>
|
|
# IN KEY <1024 bit zone key>
|
|
# IN SIG KEY <by test.>
|
|
# IN SIG KEY <by .>
|
|
# IN NS ns.test.
|
|
# IN SIG NS <by test.>
|
|
# IN NXT my-org.test. NS SOA SIG KEY NXT
|
|
# IN SIG NXT <by test.>
|
|
#
|
|
# my-org IN KEY <1024 bit zone key>
|
|
# IN KEY <1024 bit zone key>
|
|
# IN SIG KEY <by test.>
|
|
# IN NS ns1.my-org.test.
|
|
# IN NS ns2.my-org.test.
|
|
# IN NXT them.test. NS SIG KEY NXT
|
|
# IN SIG NXT <by test.>
|
|
#
|
|
# them IN KEY 0xC100 3 1
|
|
# IN SIG KEY <by test.>
|
|
# IN NS ns1.them.test.
|
|
# IN NS ns2.them.test.
|
|
# IN NXT test. NS SIG KEY NXT
|
|
# IN SIG NXT <by test.>
|
|
|
|
In this zone file fragment, "my-org" is a delegation point of
|
|
interest with two registered public keys. Presumably, one key
|
|
is for signatures generated currently and the other is for still
|
|
living and valid but older signatures. "them" is another
|
|
delegation point, with a NULL key. This signifies that this zone
|
|
is unsecured.
|
|
|
|
To analyze the performance impact of the storing of keys, the
|
|
number of bytes used to represent the RRs in the procotol format
|
|
is used. The actual number of bytes stored will likely be
|
|
higher, accounting for data structure overhead and alignment.
|
|
The actual number of bytes transferred will be lower due to DNS
|
|
name compression.
|
|
|
|
The number of bytes for my-org's two 1024-bit keys, two NS
|
|
records, NXT and the associated signatures is 526. The bytes
|
|
needed for them (with the NULL key) is 346. Currently, there
|
|
are close to 2 million entries in com., so if we take my-org as
|
|
a typical domain, over 1GB on memory will be needed for com.
|
|
|
|
The zone keys used in the example are set to 1024 bits. This
|
|
number may range from as low as 512 bits upwards to over 3000
|
|
bits. To scale the above numbers to a different key size,
|
|
multiply the difference in key sizes by 4 for my-org and by 2
|
|
for them, and adjust the numbers accordingly.
|
|
|
|
The increased size of the data held for the zone cuts will have
|
|
two impacts at the transport and below layers. Bandwidth beyond
|
|
that currently needed will be used to carry the KEY records.
|
|
The inclusion of all of the child's keys will also push DNS over
|
|
the UDP size limit and start using TCP - which could cause
|
|
critical problems for current heavily used name servers, like
|
|
the roots.
|
|
|
|
Another impact, not illustrated by the example, is the frequency
|
|
of updates. If each time a public key for my-org is added or
|
|
deleted, the SOA serial number will have to increase, and the
|
|
SOA signed again. If an average zone changes its keys(s) once
|
|
per month, there will be on average 45 updates per minute in a
|
|
zone of 2 million delegations.
|
|
|
|
(The multiple algorithms issue is an extension of multiple keys. The
|
|
example should be updated to show at least a DSS key as well as an RSA
|
|
key.)
|
|
|
|
1.2 Security Incident Recovery (w/ respect to keys only)
|
|
|
|
Once a zone administrator is alerted that any key's private
|
|
counterpart has been discovered (exposed), the first action to
|
|
be taken is to stop advertising the public key in DNS. This
|
|
doesn't end the availability of the key - it will be residing in
|
|
caches - but is the closest action resembling revokation
|
|
available in DNS.
|
|
|
|
Stopping the advertisement in the zone's name servers is as
|
|
quick as altering the master file and restarting the name
|
|
server. Having to do this in two places will will only delay
|
|
the time until the recovery is complete.
|
|
|
|
For example, a registrar of a top level domain has decided to
|
|
update its zone only on Mondays and Fridays due to the size of
|
|
the zone. A customer/delegatee is the victim of a break in, in
|
|
which one of the items taken is the file of private keys used to
|
|
sign DNS data. If this occurs on a Tuesday, the thief has until
|
|
Friday to use the keys before they disappear from the DNS, even
|
|
if the child stops publishing them immediately.
|
|
|
|
If the public key set is in the parent zone, and the parent zone
|
|
is not able to make the change quickly, the public key cannot be
|
|
revoked quickly. If the parent only refers to there being a key
|
|
at the child zone, then the child has the agility to change the
|
|
keys - even issue a NULL key, which will force all signatures in
|
|
the zone to become suspect.
|
|
|
|
1.3 DNS Clarifications
|
|
|
|
RFC 2181, section 6, clarifies the status of data appearing at a
|
|
zone cut. Data at a zone cut is served authoritatively from the
|
|
servers listed in the NS set present at the zone cut. The data
|
|
is not (necessarily) served authoritatively from the parent.
|
|
(The exception is in servers handling both the parent and child
|
|
zone.)
|
|
|
|
Section 6 also mentions that there are two exceptions created by
|
|
DNSSEC, the NXT single record set and the KEY set. This
|
|
proposal addresses the exception relating to the KEY set,
|
|
limiting its severity (but falling short of removing it
|
|
altogether). By limiting the exception, we will be simplifying
|
|
DNS.
|
|
|
|
1.4 Liability
|
|
|
|
Liability is a legal concept, so it is not wise to attempt an
|
|
engineering solution to it. However, the perceived liability
|
|
incurred in using DNSSEC by registrars may prevent the adoption
|
|
of DNSSEC. Hence DNSSEC should be engineered in such a away to
|
|
address the concern.
|
|
|
|
One source of liability is the notion that by advertising a
|
|
public key for a child zone, a parent zone is providing a
|
|
service of security. With that comes responsibility. By having
|
|
the parent merely indicate that a child has a key (or has no
|
|
key), the parent is providing less in the way of security. If
|
|
the parent is wrong, the potential loss is less. Instead of
|
|
falsely authenticated data, configuration errors will be
|
|
apparent to the resolving client.
|
|
|
|
2 The Proposal
|
|
|
|
The proposal is to introduce a new key type which indicates
|
|
whether the delegated zone is running secured or not. Running
|
|
secured is either a zone signed with at least one key, an
|
|
experimental zone, or a zone with only NULL keys published.
|
|
|
|
The Zone Referral Key will resemble the NULL key in syntax.
|
|
There will be a flags field, an algorithm field, and a protocol
|
|
field, but no public key material. The Referral Key is signed
|
|
by the parent zone, as was the public key set in RFC 2065.
|
|
There is only one Referral Key RR present.
|
|
|
|
The Referral Key flags field will have the following values:
|
|
Field Bit(s) Value Meaning
|
|
|
|
A/C 0- 1 0b01 indicates a key will be found
|
|
0b11 indicates a key will not be found
|
|
0b?0 error (referral cannot encrypt)
|
|
XT 2 0 no extended flags are needed
|
|
Z 4- 5 0 must be zero for all keys
|
|
NAMTYP 6- 7 0b11 this is a referral to a zone key
|
|
Z 8-11 0 must be zero for all keys
|
|
SIG 12-15 0 must be zero for a referral key
|
|
|
|
The legal values of the flags field are (in summary):
|
|
|
|
Hex Value Indicates
|
|
0x4300 The delegation has a key record set
|
|
0xC300 The delegation has no key record
|
|
|
|
Other values are not valid for Referral Keys (but may be valid
|
|
for other keys).
|
|
|
|
The Protocol field must be set to 3, the DNSSEC protocol value.
|
|
|
|
The Algorithm field must be 0.
|
|
|
|
The algorithm is not important at this point. So long as the searcher
|
|
knows to expect a key set at the delegated zone's apex, a secure chain
|
|
is possible. One the key set is retrieved and verified, then the
|
|
algorithms used in the delegated zone are known. (The issue is that a
|
|
zone may be signed in algorithm 1 and not 3, 3 and not 1, both, etc.,
|
|
and a secure resolver must know this in order to set signature arrival
|
|
expectations.
|
|
|
|
2.1 Example
|
|
|
|
The Referral key for my-org.test. and them.test. would appear as
|
|
the following in the zone master file:
|
|
|
|
my-org.test. IN KEY 0x4300 3 0
|
|
them.test. IN KEY 0xC300 3 0
|
|
|
|
In the example introduced earlier, the master file would change
|
|
to the following.
|
|
|
|
# $ORIGIN test.
|
|
# @ IN SOA <SOA data>
|
|
# IN SIG SOA <by test.>
|
|
# IN KEY <1024 bit zone key>
|
|
# IN SIG KEY <by test.>
|
|
# IN SIG KEY <by .>
|
|
# IN NS ns.test.
|
|
# IN SIG NS <by test.>
|
|
# IN NXT my-org.test. NS SOA SIG KEY NXT
|
|
# IN SIG NXT <by test.>
|
|
#
|
|
# my-org IN KEY 0x4300 3 0
|
|
# IN SIG KEY <by test.>
|
|
# IN NS ns1.my-org.test.
|
|
# IN NS ns2.my-org.test.
|
|
# IN NXT them.test. NS SIG KEY NXT
|
|
# IN SIG NXT <by test.>
|
|
#
|
|
# them IN KEY 0xC300 3 1
|
|
# IN SIG KEY <by test.>
|
|
# IN NS ns1.them.test.
|
|
# IN NS ns2.them.test.
|
|
# IN NXT test. NS SIG KEY NXT
|
|
# IN SIG NXT <by test.>
|
|
|
|
3 Analysis
|
|
|
|
By removing the public keys from the parent's master file, the
|
|
parent is no longer a road block during an emergency removal of
|
|
keys. A parent zone is unchanged as a zone changes from NULL
|
|
keys to experimental keys to fully signed. The parent is also
|
|
not providing a security service, other than to authentically
|
|
claim the existence of a KEY record set - akin to the "hints" of
|
|
the name servers.
|
|
|
|
The change also improves the prospect for performance. The need
|
|
for multiple KEY RR's, each one on the order of 100 bytes, is
|
|
removed and replaced by a single KEY RR of the order of 25
|
|
bytes. Saving bytes reduces the need to use TCP to avoid
|
|
truncated responses. Also, the need for updating the zone drops
|
|
- no longer will there be updates for each key change.
|
|
|
|
As far as the statements by RFC 2181 conerning authority levels,
|
|
the Referral Key is not authortative and would be superseeded by
|
|
a verified set of the real zone keys. The only caveat is that
|
|
once the verified set of keys expire (assuming the parent has to
|
|
learn the keys from another server), the Referal Key must
|
|
reappear. This is an example of what has been labelled "mount-
|
|
like semantics."
|
|
|
|
[No reference for mount-like semantics has yet been found.]
|
|
|
|
The last point is important. This requires the "mount-like
|
|
semantics" that have been discussed for the BIND name servers.
|
|
Once hints are overridden by learned, authorititative and
|
|
verified data, the hints are not discarded. Hints in this state
|
|
are stored and become visible when the learned data expires.
|
|
|
|
4 IANA Considerations
|
|
|
|
Other than using a new value in the flags field of the KEY RR,
|
|
no new number assignments are needed. The flags field is not
|
|
under the control of IANA as of yet. There are no requirements
|
|
placed on IANA by this draft.
|
|
|
|
5 Security Considerations
|
|
|
|
There has been some debate about whether the Referral key should
|
|
be treated as a hint - just like the NS records. If so, then
|
|
there is no need to sign the Referral Key, and an unsigned
|
|
(hence non-authenticated) security record is of little value.
|
|
So, is the Referral Key even needed?
|
|
|
|
Authentication in DNSSEC is done from the data "back" towards a
|
|
trusted point - e.g., "up" to the root. Since the
|
|
authentication is done by going repeatedly from child to parent,
|
|
why bother having the parent indicate the status of the child?
|
|
|
|
The answer is in the scenario in which a resolver somewhere has
|
|
obtained data which fails the verification process. Perhaps the
|
|
signature is wrong, a key in the chain of trust is unavailable,
|
|
the set should have had a signature, but none is found (or vice
|
|
versa), or the trail of signed-by names is not acceptable. In
|
|
this case, the resolver needs to find the authoritative zone,
|
|
its status and its name server set.
|
|
|
|
If a zone is being attacked by a masquerader, and parents do not
|
|
make any statements about the security of child zones, then an
|
|
easy and successfull attack may occur. An attacker only needs
|
|
to supply either fake name server records or glue records to
|
|
redirect queries.
|
|
|
|
While this attack will not be stopped as far as denial of
|
|
service, the masquerader can be stopped from being accepted as
|
|
an authoritative source if the parent of the zone claims the
|
|
child is secure and signs the public keys of the true child and
|
|
not the masquerader.
|
|
|
|
The masquerader cannot successfully claim that the zone is
|
|
unsigned, because it must have a zone key signed by the parent.
|
|
NULL or not, the key would not be trusted by the resolver,
|
|
assuming the parent has not also been duped. The resolver,
|
|
sensing this, should report an error or security incident, and
|
|
not accept data.
|
|
|
|
6 Acknowledgements
|
|
|
|
John Gilmore originally raised the issues that have led to this
|
|
document.
|
|
|
|
7 Author's addresses
|
|
|
|
Edward Lewis Jerry Scharf
|
|
<lewis@tislabs.com> <scharf@vix.com>
|
|
3060 Washinton Rd (Rte 97)
|
|
Glenwood, MD 21738
|
|
+1(443)259-2352
|
|
|
|
8 References
|
|
|
|
RFC 2181 "Clarifications to the DNS Specification", Elz and Bush
|
|
RFC 2535 "Domain Name System Security Extensions", Eastlake
|
|
|
|
9 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 implmentation 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."
|
|
|
|
This draft expires on October 1, 1999
|