520 lines
20 KiB
Plaintext
520 lines
20 KiB
Plaintext
|
|
Internet Draft Johan Ihren
|
|
draft-ihren-dnsext-threshold-validation-00.txt Autonomica
|
|
February 2003
|
|
Expires in six months
|
|
|
|
|
|
Threshold Validation:
|
|
|
|
A Mechanism for Improved Trust and Redundancy for DNSSEC Keys
|
|
|
|
|
|
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.
|
|
|
|
|
|
Abstract
|
|
|
|
This memo documents a proposal for a different method of validation
|
|
for DNSSEC aware resolvers. The key change is that by changing from
|
|
a model of one Key Signing Key, KSK, at a time to multiple KSKs it
|
|
will be possible to increase the aggregated trust in the signed
|
|
keys by leveraging from the trust associated with the different
|
|
signees.
|
|
|
|
By having multiple keys to chose from validating resolvers get the
|
|
opportunity to use local policy to reflect actual trust in
|
|
different keys. For instance, it is possible to trust a single,
|
|
particular key ultimately, while requiring multiple valid
|
|
signatures by less trusted keys for validation to succeed.
|
|
Furthermore, with multiple KSKs there are additional redundancy
|
|
benefits available since it is possible to roll over different KSKs
|
|
at different times which may make rollover scenarios easier to
|
|
manage.
|
|
|
|
Contents
|
|
|
|
1. Terminology
|
|
2. Introduction and Background
|
|
|
|
3. Trust in DNSSEC Keys
|
|
3.1. Key Management, Split Keys and Trust Models
|
|
3.2. Trust Expansion: Authentication versus Authorization
|
|
|
|
4. Proposed Semantics for Signing the KEY Resource Record
|
|
Set
|
|
4.1. Packet Size Considerations
|
|
|
|
5. Proposed Use of Multiple "Trusted Keys" in a Validating
|
|
Resolver
|
|
5.1. Not All Possible KSKs Need to Be Trusted
|
|
5.2. Possible to do Threshold Validation
|
|
5.3. Not All Trusted Keys Will Be Available
|
|
|
|
6. Additional Benefits from Having Multiple KSKs
|
|
6.1. More Robust Key Rollovers
|
|
6.2. Evaluation of Multiple Key Distribution Mechanisms
|
|
|
|
7. Security Considerations
|
|
8. IANA Considerations.
|
|
9. References
|
|
9.1. Normative.
|
|
9.2. Informative.
|
|
10. Acknowledgments.
|
|
11. Authors' Address
|
|
|
|
|
|
1. Terminology
|
|
|
|
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
|
|
and "MAY" in this document are to be interpreted as described in
|
|
RFC 2119.
|
|
|
|
The term "zone" refers to the unit of administrative control in the
|
|
Domain Name System. "Name server" denotes a DNS name server that is
|
|
authoritative (i.e. knows all there is to know) for a DNS zone,
|
|
typically the root zone. A "resolver", is a DNS "client", i.e. an
|
|
entity that sends DNS queries to authoritative nameservers and
|
|
interpret the results. A "validating resolver" is a resolver that
|
|
attempts to perform DNSSEC validation on data it retrieves by doing
|
|
DNS lookups.
|
|
|
|
|
|
2. Introduction and Background
|
|
|
|
From a protocol perspective there is no real difference between
|
|
different keys in DNSSEC. They are all just keys. However, in
|
|
actual use there is lots of difference. First and foremost, most
|
|
DNSSEC keys have in-band verification. I.e. the keys are signed by
|
|
some other key, and this other key is in its turn also signed by
|
|
yet another key. This way a "chain of trust" is created. Such
|
|
chains have to end in what is referred to as a "trusted key" for
|
|
validation of DNS lookups to be possible.
|
|
|
|
A "trusted key" is a the public part of a key that the resolver
|
|
acquired by some other means than by looking it up in DNS. The
|
|
trusted key has to be explicitly configured.
|
|
|
|
A node in the DNS hierarchy that issues such out-of-band "trusted
|
|
keys" is called a "security apex" and the trusted key for that apex
|
|
is the ultimate source of trust for all DNS lookups within that
|
|
entire subtree.
|
|
|
|
DNSSEC is designed to be able to work with more than on security
|
|
apex. These apexes will all share the problem of how to distribute
|
|
their "trusted keys" in a way that provides validating resolvers
|
|
confidence in the distributed keys.
|
|
|
|
Maximizing that confidence is crucial to the usefulness of DNSSEC
|
|
and this document tries to address this issue.
|
|
|
|
|
|
3. Trust in DNSSEC Keys
|
|
|
|
In the end the trust that a validating resolver will be able to put
|
|
in a key that it cannot validate within DNSSEC will have to be a
|
|
function of
|
|
|
|
* trust in the key issuer, aka the KSK holder
|
|
|
|
* trust in the distribution method
|
|
|
|
* trust in extra, out-of-band verification
|
|
|
|
The KSK holder needs to be trusted not to accidentally lose private
|
|
keys in public places. Furthermore it needs to be trusted to
|
|
perform correct identification of the ZSK holders in case they are
|
|
separate from the KSK holder itself.
|
|
|
|
The distribution mechanism can be more or less tamper-proof. If the
|
|
key holder publishes the public key, or perhaps just a secure
|
|
fingerprint of the key in a major newspaper it may be rather
|
|
difficult to tamper with. A key acquired that way may be easier to
|
|
trust than if it had just been downloaded from a web page.
|
|
|
|
Out-of-band verification can for instance be the key being signed
|
|
by a certificate issued by a known Certificate Authority that the
|
|
resolver has reason to trust.
|
|
|
|
3.1. Simplicity vs Trust
|
|
|
|
The fewer keys that are in use the simpler the key management
|
|
becomes. Therefore increasing the number of keys should only be
|
|
considered when the complexity is not the major concern. A perfect
|
|
example of this is the distinction between so called Key Signing
|
|
Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds
|
|
overall complexity but simplifies real life operations and was an
|
|
overall gain since operational simplification was considered to be
|
|
a more crucial issue than the added complexity.
|
|
|
|
In the case of a security apex there are additional issues to
|
|
consider, among them
|
|
|
|
* maximizing trust in the KSK received out-of-band
|
|
|
|
* authenticating the legitimacy of the ZSKs used
|
|
|
|
In some cases this will be easy, since the same entity will manage
|
|
both ZSKs and KSKs (i.e. it will authenticate itself, somewhat
|
|
similar to a self-signed certificate). In some environments it will
|
|
be possible to get the trusted key installed in the resolver end by
|
|
decree (this would seem to be a likely method within corporate and
|
|
government environments).
|
|
|
|
In other cases, however, this will possibly not be sufficient. In
|
|
the case of the root zone this is obvious, but there may well be
|
|
other cases.
|
|
|
|
3.2. Expanding the "Trust Base"
|
|
|
|
For a security apex where the ZSKs and KSK are not held by the same
|
|
entity the KSK will effectively authenticate the identity of
|
|
whoever does real operational zone signing. The amount of trust
|
|
that the data signed by a ZSK will get is directly dependent on
|
|
whether the end resolver trusts the KSK or not, since the resolver
|
|
has no OOB access to the public part of the ZSKs (for practical
|
|
reasons).
|
|
|
|
Since the KSK holder is distinct from the ZSK holder the obvious
|
|
question is whether it would then be possible to further improve
|
|
the situation by using multiple KSK holders and thereby expanding
|
|
the trust base to the union of that available to each individual
|
|
KSK holder. "Trust base" is an invented term intended to signify
|
|
the aggregate of Internet resolvers that will eventually choose to
|
|
trust a key issued by a particular KSK holder.
|
|
|
|
A crucial issue when considering trust expansion through addition
|
|
of multiple KSK holders is that the KSK holders are only used to
|
|
authenticate the ZSKs used for signing the zone. I.e. the function
|
|
performed by the KSK is basically:
|
|
|
|
"This is indeed the official ZSK holder for this zone,
|
|
I've verified this fact to the best of my abilitites."
|
|
|
|
Which can be thought of as similar to the service of a public
|
|
notary. I.e. the point with adding more KSK holders is to improve
|
|
the public trust in data signed by the ZSK holders by improving the
|
|
strength of available authentication.
|
|
|
|
Therefore adding more KSK holders, each with their own trust base,
|
|
is by definition a good thing. More authentication is not
|
|
controversial. On the contrary, when it comes to authentication,
|
|
the more the merrier.
|
|
|
|
|
|
4. Proposed Semantics for Signing the KEY Resource Record Set
|
|
|
|
In DNSSEC according to RFC2535 all KEY Resource Records are used to
|
|
sign all authoritative data in the zone, including the KEY RRset
|
|
itself, since RFC2535 makes no distinction between Key Signing
|
|
Keys, KSK, and Zone Signing Keys, ZSK. With Delegation Signer [DS]
|
|
it is possible to change this to the KEY RRset being signed with
|
|
all KSKs and ZSKs but the rest of the zone only being signed by the
|
|
ZSKs.
|
|
|
|
This proposal changes this one step further, by recommending that
|
|
the KEY RRset is only signed by the Key Signing Keys, KSK, and
|
|
explicitly not by the Zone Signing Keys, ZSK. The reason for this
|
|
is to maximize the amount of space in the DNS response packet that
|
|
is available for additional KSKs and signatures thereof. The rest
|
|
of the authoritative zone contents are as previously signed by only
|
|
the ZSKs.
|
|
|
|
4.1. Packet Size Considerations
|
|
|
|
The reason for the change is to keep down the size of the aggregate
|
|
of KEY RRset plus SIG(KEY) that resolvers will need to acquire to
|
|
perform validation of data below a security apex. For DNSSEC data
|
|
to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be
|
|
set, and therefore the allowed packet size can be assumed to be at
|
|
least the EDNS0 minimum of 4000 bytes.
|
|
|
|
When querying for KEY + SIG(KEY) for "." (the case that is assumed
|
|
to be most crucial) the size of the response packet after the
|
|
change to only sign the KEY RR with the KSKs break down into a
|
|
rather large space of possibilities. Here are a few examples for
|
|
the possible alternatives for different numbers of KSKs and ZSKs
|
|
for some different key lengths (all RSA keys, with a public
|
|
exponent that is < 254). This is all based upon the size of the
|
|
response for the particular example of querying for
|
|
|
|
". KEY IN"
|
|
|
|
with a response of entire KEY + SIG(KEY) with the authority and
|
|
additional sections empty:
|
|
|
|
ZSK/768 and KSK/1024 (real small)
|
|
Max 12 KSK + 3 ZSK at 3975
|
|
10 KSK + 8 ZSK at 3934
|
|
8 KSK + 13 ZSK at 3893
|
|
|
|
ZSK/768 + KSK/1280
|
|
MAX 10 KSK + 2 ZSK at 3913
|
|
8 KSK + 9 ZSK at 3970
|
|
6 KSK + 15 ZSK at 3914
|
|
|
|
ZSK/768 + KSK/1536
|
|
MAX 8 KSK + 4 ZSK at 3917
|
|
7 KSK + 8 ZSK at 3938
|
|
6 KSK + 12 ZSK at 3959
|
|
|
|
ZSK/768 + KSK/2048
|
|
MAX 6 KSK + 5 ZSK at 3936
|
|
5 KSK + 10 ZSK at 3942
|
|
|
|
ZSK/1024 + KSK/1024
|
|
MAX 12 KSK + 2 ZSK at 3943
|
|
11 KSK + 4 ZSK at 3930
|
|
10 KSK + 6 ZSK at 3917
|
|
8 KSK + 10 ZSK at 3891
|
|
|
|
ZSK/1024 + KSK/1536
|
|
MAX 8 KSK + 3 ZSK at 3900
|
|
7 KSK + 6 ZSK at 3904
|
|
6 KSK + 9 ZSK at 3908
|
|
|
|
ZSK/1024 + KSK/2048
|
|
MAX 6 KSK + 4 ZSK at 3951
|
|
5 KSK + 8 ZSK at 3972
|
|
4 KSK + 12 ZSK at 3993
|
|
|
|
Note that these are just examples and this document is not making
|
|
any recommendations on suitable choices of either key lengths nor
|
|
number of different keys employed at a security apex.
|
|
|
|
This document does however, based upon the above figures, make the
|
|
recommendation that at a security apex that expects to distribute
|
|
"trusted keys" the KEY RRset should only be signed with the KSKs
|
|
and not with the ZSKs to keep the size of the response packets
|
|
down.
|
|
|
|
|
|
5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver
|
|
|
|
In DNSSEC according to RFC2535[RFC2535] validation is the process
|
|
of tracing a chain of signatures (and keys) upwards through the DNS
|
|
hierarchy until a "trusted key" is reached. If there is a known
|
|
trusted key present at a security apex above the starting point
|
|
validation becomes an exercise with a binary outcome: either the
|
|
validation succeeds or it fails. No intermediate states are
|
|
possible.
|
|
|
|
With multiple "trusted keys" (i.e. the KEY RRset for the security
|
|
apex signed by multiple KSKs) this changes into a more complicated
|
|
space of alternatives. From the perspective of complexity that may
|
|
be regarded as a change for the worse. However, from a perspective
|
|
of maximizing available trust the multiple KSKs add value to the
|
|
system.
|
|
|
|
5.1. Possible to do Threshold Validation
|
|
|
|
With multiple KSKs a new option that opens for the security
|
|
concious resolver is to not trust a key individually. Instead the
|
|
resolver may decide to require the validated signatures to exceed a
|
|
threshold. For instance, given M trusted keys it is possible for
|
|
the resolver to require N-of-M signatures to treat the data as
|
|
validated.
|
|
|
|
I.e. with the following pseudo-configuration in a validating
|
|
resolver
|
|
|
|
security-apex "." IN {
|
|
keys { ksk-1 .... ;
|
|
ksk-2 .... ;
|
|
ksk-3 .... ;
|
|
ksk-4 .... ;
|
|
ksk-5 .... ;
|
|
};
|
|
validation {
|
|
# Note that ksk-4 is not present below
|
|
keys { ksk-1; ksk-2; ksk-3; ksk-5; };
|
|
# 3 signatures needed with 4 possible keys, aka 75%
|
|
needed-signatures 3;
|
|
};
|
|
};
|
|
|
|
we configure five trusted keys for the root zone, but require two
|
|
valid signatures for the top-most KEY for validation to
|
|
succeed. I.e. threshold validation does not force multiple
|
|
signatures on the entire signature chain, only on the top-most
|
|
signature, closest to the security apex for which the resolver has
|
|
trusted keys.
|
|
|
|
5.2. Not All Trusted Keys Will Be Available
|
|
|
|
With multiple KSKs held and managed by separate entities the end
|
|
resolvers will not always manage to get access to all possible
|
|
trusted keys. In the case of just a single KSK this would be fatal
|
|
to validation and necessary to avoid at whatever cost. But with
|
|
several fully trusted keys available the resolver can decide to
|
|
trust several of them individually. An example based upon more
|
|
pseudo-configuration:
|
|
|
|
security-apex "." IN {
|
|
keys { ksk-1 .... ;
|
|
ksk-2 .... ;
|
|
ksk-3 .... ;
|
|
ksk-4 .... ;
|
|
ksk-5 .... ;
|
|
};
|
|
validation {
|
|
# Only these two keys are trusted independently
|
|
keys { ksk-1; ksk-4; };
|
|
# With these keys a single signature is sufficient
|
|
needed-signatures 1;
|
|
};
|
|
};
|
|
|
|
Here we have the same five keys and instruct the validating
|
|
resolver to fully trust data that ends up with just one signature
|
|
from by a fully trusted key.
|
|
|
|
The typical case where this will be useful is for the case where
|
|
there is a risk of the resolver not catching a rollover event by
|
|
one of the KSKs. By doing rollovers of different KSKs with
|
|
different schedules it is possible for a resolver to "survive"
|
|
missing a rollover without validation breaking. This improves
|
|
overall robustness from a management point of view.
|
|
|
|
5.3. Not All Possible KSKs Need to Be Trusted
|
|
|
|
With just one key available it simply has to be trusted, since that
|
|
is the only option available. With multiple KSKs the validating
|
|
resolver immediately get the option of implementing a local policy
|
|
of only trusting some of the possible keys.
|
|
|
|
This local policy can be implemented either by simply not
|
|
configuring keys that are not trusted or, possibly, configure them
|
|
but specify to the resolver that certain keys are not to be
|
|
ultimately trusted alone.
|
|
|
|
|
|
6. Additional Benefits from Having Multiple KSKs
|
|
|
|
6.1. More Robust Key Rollovers
|
|
|
|
With only one KSK the rollover operation will be a delicate
|
|
operation since the new trusted key needs to reach every validating
|
|
resolver before the old key is retired. For this reason it is
|
|
expected that long periods of overlap will be needed.
|
|
|
|
With multiple KSKs this changes into a system where different
|
|
"series" of KSKs can have different rollover schedules, thereby
|
|
changing from one "big" rollover to several "smaller" rollovers.
|
|
|
|
If the resolver trusts several of the available keys individually
|
|
then even a failure to track a certain rollover operation within
|
|
the overlap period will not be fatal to validation since the other
|
|
available trusted keys will be sufficient.
|
|
|
|
6.2. Evaluation of Multiple Key Distribution Mechanisms
|
|
|
|
Distribution of the trusted keys for the DNS root zone is
|
|
recognized to be a difficult problem that ...
|
|
|
|
With only one trusted key, from one single "source" to distribute
|
|
it will be difficult to evaluate what distribution mechanism works
|
|
best. With multiple KSKs, held by separate entitites it will be
|
|
possible to measure how large fraction of the resolver population
|
|
that is trusting what subsets of KSKs.
|
|
|
|
|
|
7. Security Considerations
|
|
|
|
From a systems perspective the simplest design is arguably the
|
|
best, i.e. one single holder of both KSK and ZSKs. However, if that
|
|
is not possible in all cases a more complex scheme is needed where
|
|
additional trust is injected by using multiple KSK holders, each
|
|
contributing trust, then there are only two alternatives
|
|
available. The first is so called "split keys", where a single key
|
|
is split up among KSK holders, each contributing trust. The second
|
|
is the multiple KSK design outlined in this proposal.
|
|
|
|
Both these alternatives provide for threshold mechanisms. However
|
|
split keys makes the threshold integral to the key generating
|
|
mechanism (i.e. it will be a property of the keys how many
|
|
signatures are needed). In the case of multiple KSKs the threshold
|
|
validation is not a property of the keys but rather local policy in
|
|
the validating resolver. A benefit from this is that it is possible
|
|
for different resolvers to use different trust policies. Some may
|
|
configure threshold validation requiring multiple signatures and
|
|
specific keys (optimizing for security) while others may choose to
|
|
accept a single signature from a larger set of keys (optimizing for
|
|
redundancy). Since the security requirements are different it would
|
|
seem to be a good idea to make this choice local policy rather than
|
|
global policy.
|
|
|
|
Furthermore, a clear issue for validating resolvers will be how to
|
|
ensure that they track all rollover events for keys they
|
|
trust. Even with operlap during the rollover (which is clearly
|
|
needed) there is still a need to be exceedingly careful not to miss
|
|
any rollovers (or fail to acquire a new key) since without this
|
|
single key validation will fail. With multiple KSKs this operation
|
|
becomes more robust, since different KSKs may roll at different
|
|
times according to different rollover schedules and losing one key,
|
|
for whatever reason, will not be crucial unless the resolver
|
|
intentionally chooses to be completely dependent on that exact key.
|
|
|
|
8. IANA Considerations.
|
|
|
|
NONE.
|
|
|
|
|
|
9. References
|
|
|
|
9.1. Normative.
|
|
|
|
[RFC2535] Domain Name System Security Extensions. D. Eastlake.
|
|
March 1999.
|
|
|
|
[RFC3090] DNS Security Extension Clarification on Zone Status.
|
|
E. Lewis. March 2001.
|
|
|
|
|
|
9.2. Informative.
|
|
|
|
[RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
|
|
(DNS). D. Eastlake 3rd. May 2001.
|
|
|
|
[RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad.
|
|
December 2001.
|
|
|
|
[DS] Delegation Signer Resource Record.
|
|
O. Gudmundsson. October 2002. Work In Progress.
|
|
|
|
10. Acknowledgments.
|
|
|
|
Bill Manning came up with the original idea of moving complexity
|
|
from the signing side down to the resolver in the form of threshold
|
|
validation. I've also had much appreciated help from (in no
|
|
particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and
|
|
Olaf Kolkman.
|
|
|
|
|
|
11. Authors' Address
|
|
Johan Ihren
|
|
Autonomica AB
|
|
Bellmansgatan 30
|
|
SE-118 47 Stockholm, Sweden
|
|
johani@autonomica.se
|