DNSSEC Operational Practices, Version 2NLnet LabsKruislaan 419Amsterdam1098 VAThe Netherlandsolaf@nlnetlabs.nlhttp://www.nlnetlabs.nlmiek@miek.nl
Operations and Management
DNSOPDNSSECoperational
This document describes a set of practices for operating the
DNS with security extensions (DNSSEC). The target audience is
zone administrators deploying DNSSEC.
The document discusses operational aspects of using keys and
signatures in the DNS. It discusses issues of key generation,
key storage, signature generation, key rollover, and related
policies.
This document obsoletes RFC 2541,
as it covers more operational ground and gives more up-to-date requirements
with respect to key sizes and the new DNSSEC specification.
This document describes how to run a DNS Security
(DNSSEC)-enabled environment. It is intended for operators who
have knowledge of the DNS (see RFC
1034 and RFC 1035) and
want to deploy DNSSEC. See RFC
4033 for an introduction to DNSSEC, RFC 4034 for the newly introduced
Resource Records (RRs), and RFC
4035 for the protocol changes.
During workshops and early operational deployment tests,
operators and system administrators have gained experience
about operating the DNS with security extensions (DNSSEC).
This document translates these experiences into a set of
practices for zone administrators. At the time of writing,
there exists very little experience with DNSSEC in production
environments; this document should therefore explicitly not be
seen as representing 'Best Current Practices'. [OK: Is this
document ripe enough to shoot for BCP?]
The procedures herein are focused on the maintenance of signed
zones (i.e., signing and publishing zones on authoritative
servers). It is intended that maintenance of zones such as
re-signing or key rollovers be transparent to any verifying
clients on the Internet.
The structure of this document is as follows. In , we discuss the importance of keeping the
"chain of trust" intact. Aspects of key generation and
storage of private keys are discussed in ; the focus in this section is mainly on the
private part of the key(s). describes considerations
concerning the public part of the keys. Since these public keys
appear in the DNS one has to take into account all kinds of
timing issues, which are discussed in . and
deal with the rollover, or supercession, of keys. Finally,
discusses considerations on how
parents deal with their children's public keys in order to
maintain chains of trust.
The typographic conventions used in
this document are explained in .
Since this is a document with operational suggestions and
there are no protocol specifications, the RFC 2119 language does not apply.
This document [OK: when approved] obsoletes RFC 4641.
[OK: Editorial comments and questions are indicated by square
brackets and editor innitials]
It is assumed that the reader is familiar with the concept
of asymmetric keys on which DNSSEC is based (public key
cryptography RFC4949). Therefore,
this document will use the term 'key' rather loosely. Where
it is written that 'a key is used to sign data' it is
assumed that the reader understands that it is the private
part of the key pair that is used for signing. It is also
assumed that the reader understands that the public part of
the key pair is published in the DNSKEY Resource Record and
that it is the public part that is used in key exchanges.
In this document, we will be using a number of time-related
terms. The following definitions apply:
"Signature validity period" The period that a signature
is valid. It starts at the time specified in the
signature inception field of the RRSIG RR and ends at
the time specified in the expiration field of the RRSIG
RR.
"Signature publication period" Time after which a
signature (made with a specific key) is replaced with a
new signature (made with the same key). This replacement
takes place by publishing the relevant RRSIG in the
master zone file. After one stops publishing an RRSIG
in a zone, it may take a while before the RRSIG has
expired from caches and has actually been removed from
the DNS.
"Key effectivity period" The period during which a key
pair is expected to be effective. This period is defined
as the time between the first inception time stamp and
the last expiration date of any signature made with this
key, regardless of any discontinuity in the use of the
key. The key effectivity period can span multiple
signature validity periods.
"Maximum/Minimum Zone Time to Live (TTL)" The maximum or
minimum value of the TTLs from the complete set of RRs
in a zone. Note that the minimum TTL is not the same as
the MINIMUM field in the SOA RR. See for more information.
Maintaining a valid chain of trust is important because
broken chains of trust will result in data being marked as
Bogus (as defined in Section 5), which
may cause entire (sub)domains to become invisible to
verifying clients. The administrators of secured zones have
to realize that their zone is, to verifying clients, part of a
chain of trust.
As mentioned in the introduction, the procedures herein are
intended to ensure that maintenance of zones, such as re-signing or
key rollovers, will be transparent to the verifying clients on the
Internet.
Administrators of secured zones will have to keep in mind that data
published on an authoritative primary server will not be
immediately seen by verifying clients; it may take some time for
the data to be transferred to other secondary authoritative
nameservers and clients may be fetching data from caching
non-authoritative servers. In this light, note that
the time for a zone transfer from master to slave is negligible when
using NOTIFY and incremental transfer
(IXFR) . It increases when full zone
transfers (AXFR) are used in combination
with NOTIFY. It increases even more if you rely on full zone
transfers based on only the SOA timing parameters for refresh.
For the verifying clients, it is important that data from
secured zones can be used to build chains of trust
regardless of whether the data came directly from an
authoritative server, a caching nameserver, or some middle
box. Only by carefully using the available timing parameters
can a zone administrator ensure that the data necessary for
verification can be obtained.
The responsibility for maintaining the chain of trust is
shared by administrators of secured zones in the chain of
trust. This is most obvious in the case of a 'key
compromise' when a trade-off between maintaining a valid
chain of trust and replacing the compromised keys as soon as
possible must be made. Then zone administrators will have
to make a trade-off, between keeping the chain of trust
intact -- thereby allowing for attacks with the compromised
key -- or deliberately breaking the chain of trust and making
secured subdomains invisible to security-aware
resolvers. Also see .
This section describes a number of considerations with
respect to the security of keys. It deals with the
generation, effectivity period, size, and storage of private keys.
The DNSSEC validation protocol does not distinguish between
different types of DNSKEYs. All DNSKEYs can be used during the validation. In
practice, operators use Key Signing and Zone Signing Keys and
use the so-called Secure Entry Point (SEP)
flag to distinguish between them during operations.
The dynamics and considerations are discussed below.
To make zone re-signing and key rollover procedures easier
to implement, it is possible to use one or more keys as Key
Signing Keys (KSKs). These keys will only sign the apex DNSKEY
RRSet in a zone. Other keys can be used to sign all the RRSets
in a zone and are referred to as Zone Signing Keys (ZSKs). In
this document, we assume that KSKs are the subset of
keys that are used for key exchanges with the parent and
potentially for configuration as trusted anchors -- the
SEP keys. In this document, we assume a one-to-one mapping between
KSK and SEP keys and we assume the SEP flag to be set on all KSKs.
Differentiating between the KSK and ZSK functions has
several advantages:
No parent/child interaction is required when ZSKs are
updated.[OK: Bullet removed, strawman Paul Hoffman]
As the KSK is only used to sign a key set, which is most
probably updated less frequently than other data in the zone,
it can be stored separately from and in a safer location
than the ZSK.A KSK can have a longer key effectivity period.
For almost any method of key management and zone signing, the KSK is
used less frequently than the ZSK. Once a key set is signed with the
KSK, all the keys in the key set can be used as ZSKs. If a
ZSK is compromised, it can be simply dropped from the
key set. The new key set is then re-signed with the KSK.
Given the assumption that for KSKs the SEP flag is set, the
KSK can be distinguished from a ZSK by examining the flag
field in the DNSKEY RR. If the flag field is an odd number it
is a KSK. If it is an even number it is a ZSK.
The Zone Signing Key can be used to sign all the data in
a zone on a regular basis. When a Zone Signing Key is to be
rolled, no interaction with the parent is needed. This
allows for signature validity periods on the order
of days.
The Key Signing Key is only to be used to sign the DNSKEY
RRs in a zone. If a Key Signing Key is to be rolled over,
there will be interactions with parties other than the
zone administrator. If there is a parent zone, these can
include the registry of the parent zone or administrators
of verifying resolvers that have the particular key
configured as secure entry points. If this is a trust
anchor, everyone relying on the trust anchor needs to roll
over to the new key. The latter may be subject to
stability costs if automated trust-anchor rollover
mechanisms (such as e.g. RFC5011) are
not in place. Hence, the key effectivity period of these
keys can and should be made much longer.
There are two schools of thought on rolling a KSK that is
not a trust anchor [OK: One can never be sure a KSK is
_not_ a trust anchor]:
It should be done regularly (possibly every few months) so that
a key rollover remains an operational routine. It should only be done when it is known or strongly suspected
that the key has been compromised in order to reduce the
stability issues on systems where the rollover does not happen
cleanly.
There is no widespread agreement on which of these two schools of
thought is better for different deployments of DNSSEC. There is a
stability cost every time a non-anchor KSK is rolled over, but it
is possibly low if the communication between the child and the
parent is good. On the other hand, the only completely effective
way to tell if the communication is good is to test it
periodically. Thus, rolling a KSK with a parent is only done for
two reasons: to test and verify the rolling system to prepare for
an emergency, and in the case of an actual emergency.
[OK: The paragraph below is a straw-man by Paul Hoffman]
Because of the difficulty of getting all users of a trust anchor to
replace an old trust anchor with a new one, a KSK that is a trust
anchor should never be rolled unless it is known or strongly
suspected that the key has been compromised.
[OK: This is an alternative straw-man by Olaf Kolkman] The
same operational concerns apply to the rollover of KSKs
that are used as trust-anchors. Since the administrator of
a zone can not be certain that the zone's KSK is in use as
a trust-anchor she will have to assume that a rollover will
cause a stability cost for the users that did configure her
key as a trust-anchor. Those costs can be minimized by
automating the rollover RFC5011 and by rolling the key
regularly, and advertising such, so that the operators of
recursive nameservers will put the appropriate mechanism in
place to deal with these stability costs, or, in other words,
budget for these costs instead of incuring them unexpectedly.
In an earlier version of this document we made a
differentiation between KSKs used for zones that are high in
the DNS hierarchy versus KSKs used for zones low in that
hierarchy. We have come to realize that there are other
considerations that argue such differentiation does not need
to be made.
Longer keys are not useful because the crypto guidance is
that everyone should use keys that no one can break. Also,
it is impossible to judge which zones are more or less
valuable to an attacker. An attack can only be used if the
compromise is unnoticed and the attacker can act as an
man-in-the-middle attack (MITM) in an unnoticed way. If .example
is compromised and the attacker forges answers for
somebank.example and sends them out as an MITM, when the attack
is discovered it will be simple to prove that .example has been
compromised and the KSK will be rolled. Defining a
long-term successful attack is difficult for keys at any
level.
Careful generation of all keys is a sometimes overlooked but
absolutely essential element in any cryptographically secure
system. The strongest algorithms used with the longest keys
are still of no use if an adversary can guess enough to
lower the size of the likely key space so that it can be
exhaustively searched. Technical suggestions for the
generation of random keys will be found in RFC 4086 and NIST SP 800-900. One should
carefully assess if the random number generator used during
key generation adheres to these suggestions.
Keys with a long effectivity period are particularly sensitive as
they will represent a more valuable target and be subject to attack
for a longer time than short-period keys. It is strongly
recommended that long-term key generation occur off-line in a
manner isolated from the network via an air gap or, at a minimum,
high-level secure hardware.
From a purely operational perspective, a reasonable key effectivity
period for KSKs that have a parent zone is 13 months, with the
intent to replace them after 12 months. An intended key
effectivity period of a month is reasonable for Zone Signing Keys.
This annual rollover gives operational practice to rollovers.
Ignoring the operational perspective, a reasonable effectivity
period for KSKs that have a parent zone is of the order of 2 decades or longer.
That is, if one does not plan to test the rollover procedure, the
key should be effective essentially forever, and then only rolled
over in case of emergency.
The "operational habit" argument also applies to trust
anchor reconfiguration. If a short key effectivity period is
used and the trust anchor configuration has to be revisited
on a regular basis, the odds that the configuration tends to
be forgotten is smaller. The trade-off is against a system
that is so dynamic that administrators of the validating
clients will not be able to follow the modifications.Note
that if a trust anchor replacement is done incorrectly, the
entire zone that the trust anchor covers will become bogus
until the trust anchor is corrected.
Key effectivity periods can be made very short, as in
a few minutes. But when replacing keys one has to
take the considerations from and
into account.
There are currently two types of signature algorithms that can be
used in DNSSEC: RSA and DSA. Both are fully specified in many
freely-available documents, and both are widely considered to be
patent-free. The creation of signatures wiht RSA and DSA takes
roughly the same time, but DSA is about ten times slower for
signature verification.
We suggest the use of either RSA/SHA-1 or RSA/SHA-256 as the
preferred signature algorithms. Both have advantages and
disadvantages. RSA/SHA-1 has been deployed for many years, while
RSA/SHA-256 has only begun to be deployed. On the other hand, it
is expected that if effective attacks on either algorithm appeark,
they will appear for RSA/SHA-1 first. RSA/MD5 should not be
considered for use because RSA/MD5 will very likely be the first
common-use signature algorithm to have an effective attack.
At the time of publication, it is known that the SHA-1 hash
has cryptanalysis issues. There is work in progress on
addressing these issues. We recommend the use of public key
algorithms based on hashes stronger than SHA-1 (e.g., SHA-256), as
soon as these algorithms are available in protocol
specifications (see
and ) and implementations.
DNSSEC signing keys should be large enough to avoid all know
cryptographic attacks during the lifetime of the key. To
date, despite huge efforts, no one has broken a regular
1024-bit key; in fact, the best completed attack is
estimated to be the equivalent of a 700-bit key. An
attacker breaking a 1024-bit signing key would need expend
phenominal amounts of networked computing power in a way
that would not be detected in order to break a single key.
Because of this, it is estimated that most zones can safely
use 1024-bit keys for at least the next ten years. A
1024-bit asymmetric key has an approximate equivalent
strength of a symmetric 80-bit key.
Keys that are used as extremely high value trust anchors, or
non-anchor keys that may be difficult to roll over, may want
to use lengths longer than 1024 bits. Typically, the next
larger key size used is 2048 bits, which have the
approximate equivalent strength of a symmetric 112-bit
key. In a standard CPU, it takes about four times as long to
sign or verify with a 2048-bit key as it does with a
1024-bit key.
Another way to decide on the size of key to use is to
remember that the phenominal effort it takes for an attacker
to break a 1024-bit key is the same regardless of how the
key is used. If an attacker has the capability of breaking
a 1024-bit DNSSEC key, he also has the capability of
breaking one of the many 1024-bit TLS trust anchor keys that
are installed with web browsers. If the value of a DNSSEC
key is lower to the attacker than the value of a TLS trust
anchor, the attacker will use the resources to attack the
TLS trust anchor.
It is possible that there is a unexpected improvement in the
ability for attackers to beak keys, and that such an attack
would make it feasible to break 1024-bit keys but not
2048-bit keys. If such an improvement happens, it is likely
that there will be a huge amount of publicity, particularly
because of the large number of 1024-bit TLS trust anchors
build into popular web browsers. At that time, all 1024-bit
keys (both ones with parent zones and ones that are trust
anchors) can be rolled over and replaced with larger keys.
Earlier documents (including the previous version of this
document) urged the use of longer keys in situations where a
particular key was "heavily used". That advice may have
been true 15 years ago, but it is not true today when using
RSA or DSA algorithms and keys of 1024 bits or higher.
It is recommended that, where possible, zone private keys
and the zone file master copy that is to be signed
be kept and used in
off-line, non-network-connected, physically secure
machines only. Periodically, an application can be run to
add authentication to a zone by adding RRSIG and NSEC RRs.
Then the augmented file can be transferred.
When relying on dynamic update to manage a signed zone
, be
aware that at least one private key of the zone will have to reside on
the master server. This key is only as secure as the amount of
exposure the server receives to unknown clients and the security
of the host. Although not mandatory, one could administer the DNS
in the following way. The master that processes the dynamic
updates is unavailable from generic hosts on the Internet, it is
not listed in the NS RRSet, although its name appears in the SOA
RRs MNAME field. The nameservers in the NS RRSet are able to
receive zone updates through NOTIFY, IXFR, AXFR, or an out-of-band
distribution mechanism. This approach is known as the "hidden
master" setup.
The ideal situation is to have a one-way information flow
to the network to avoid the possibility of tampering from
the network. Keeping the zone master file on-line on the
network and simply cycling it through an off-line signer
does not do this. The on-line version could still be
tampered with if the host it resides on is compromised.
For maximum security, the master copy of the zone file
should be off-net and should not be updated based on an
unsecured network mediated communication.
In general, keeping a zone file off-line will not be
practical and the machines on which zone files are
maintained will be connected to a network. Operators are
advised to take security measures to shield unauthorized
access to the master copy.
For dynamically updated secured zones , both the master copy and
the private key that is used to update signatures on
updated RRs will need to be on-line.
Without DNSSEC, all times in the DNS are relative. The SOA
fields REFRESH, RETRY, and EXPIRATION are timers used to
determine the time elapsed after a slave server synchronized
with a master server. The Time to Live (TTL) value and the SOA
RR minimum TTL parameter are used to
determine how long a forwarder should cache data after it has
been fetched from an authoritative server. By using a
signature validity period, DNSSEC introduces the notion of an
absolute time in the DNS. Signatures in DNSSEC have an
expiration date after which the signature is marked as invalid
and the signed data is to be considered Bogus.
Because of the expiration of signatures, one should consider the
following:
We suggest the Maximum Zone TTL of your zone data to be a
fraction of your signature validity period.
If the TTL would be of similar order as the
signature validity period, then all RRSets fetched
during the validity period would be cached until the
signature expiration time. Section 7.1 of suggests that "the resolver may
use the time remaining before expiration of the
signature validity period of a signed RRSet as an
upper bound for the TTL". As a result, query load on
authoritative servers would peak at signature
expiration time, as this is also the time at which
records simultaneously expire from caches.
To avoid query load peaks, we suggest the TTL on all
the RRs in your zone to be at least a few times
smaller than your signature validity period.
We suggest the signature publication period to end at
least one Maximum Zone TTL duration before the end of
the signature validity period.
Re-signing a zone shortly before the end of the
signature validity period may cause simultaneous
expiration of data from caches. This in turn may
lead to peaks in the load on authoritative servers.
We suggest the Minimum Zone TTL to be long enough to
both fetch and verify all the RRs in the trust chain. In
workshop environments, it has been demonstrated that a low TTL (under 5 to 10
minutes) caused disruptions because of the following two
problems:
1. During validation, some data may expire before
the validation is complete. The validator should be
able to keep all data until it is completed. This
applies to all RRs needed to complete the chain of
trust: DSes, DNSKEYs, RRSIGs, and the final answers,
i.e., the RRSet that is returned for the initial
query.
2. Frequent verification causes load on recursive
nameservers. Data at delegation points, DSes, DNSKEYs, and
RRSIGs benefit from caching. The TTL on those should be
relatively long.
Slave servers will need to be able to fetch newly signed
zones well before the RRSIGs in the zone served by the
slave server pass their signature expiration time.
When a slave server is out of sync with its master
and data in a zone is signed by expired signatures,
it may be better for the slave server not to give
out any answer.
Normally, a slave server that is not able to contact
a master server for an extended period will expire a
zone. When that happens, the server will respond
differently to queries for that zone. Some servers
issue SERVFAIL, whereas others turn off the 'AA' bit
in the answers.
The time of expiration is set in the SOA
record and is relative to the last successful refresh
between the master and the slave servers. There exists no
coupling between the signature expiration of RRSIGs in
the zone and the expire parameter in the SOA.
If the server serves a DNSSEC zone, then it may well
happen that the signatures expire well before the SOA
expiration timer counts down to zero. It is not possible
to completely prevent this from happening by tweaking
the SOA parameters.
However, the effects can be minimized where the SOA
expiration time is equal to or shorter than the
signature validity period.
The consequence of an authoritative server not being
able to update a zone, whilst that zone includes expired
signatures, is that non-secure resolvers will continue to
be able to resolve data served by the particular slave
servers while security-aware resolvers will experience
problems because of answers being marked as Bogus.
We suggest the SOA expiration timer being approximately
one third or one fourth of the signature validity period.
It will allow problems with transfers from the master server
to be noticed before the actual signature times out.
We also suggest that operators of nameservers that
supply secondary services develop 'watch dogs' to spot
upcoming signature expirations in zones they slave, and
take appropriate action.
When determining the value for the expiration parameter
one has to take the following into account: What are the
chances that all my secondaries expire the zone? How quickly
can I reach an administrator of secondary servers to
load a valid zone? These questions are not DNSSEC
specific but may influence the choice of your signature
validity intervals.
Regardless of whether a zone uses periodic key rollovers in
order to practice for emergencies, or only rolls over keys in
an emergency, key rollovers are a fact of life when using
DNSSEC. Zone administrators who are in the process of rolling
their keys have to take into account that data published in
previous versions of their zone still lives in caches. When
deploying DNSSEC, this becomes an important consideration;
ignoring data that may be in caches may lead to loss of
service for clients.
The most pressing example of this occurs when zone material
signed with an old key is being validated by a resolver that
does not have the old zone key cached. If the old key is no
longer present in the current zone, this validation fails,
marking the data "Bogus". Alternatively, an attempt could be
made to validate data that is signed with a new key against
an old key that lives in a local cache, also resulting in data
being marked "Bogus". For "Zone Signing Key rollovers", there are two ways to
make sure that during the rollover data still cached
can be verified with the new key sets or newly generated
signatures can be verified with the keys still in
caches. One schema, described in ,
uses double signatures; the other uses key
pre-publication (). The pros,
cons, and recommendations are described in .
This section shows how to perform a ZSK rollover without
the need to sign all the data in a zone twice -- the
"pre-publish key rollover". This method has advantages in
the case of a key compromise. If the old key is compromised,
the new key has already been distributed in the DNS. The
zone administrator is then able to quickly switch to the new
key and remove the compromised key from the zone. Another
major advantage is that the zone size does not double, as is
the case with the double signature ZSK rollover. A small
"how-to" for this kind of rollover can be found in .
Initial version of the zone: DNSKEY 1
is the Key Signing Key. DNSKEY 10 is used to sign all
the data of the zone, the Zone Signing Key.
DNSKEY 11 is introduced into
the key set. Note that no signatures are generated with
this key yet, but this does not secure against brute
force attacks on the public key. The minimum duration
of this pre-roll phase is the time it takes for the
data to propagate to the authoritative servers plus
TTL value of the key set.
At the "new RRSIGs" stage (SOA serial
2), DNSKEY 11 is used to sign the data in the zone
exclusively (i.e., all the signatures from DNSKEY 10 are
removed from the zone). DNSKEY 10 remains published in
the key set. This way data that was loaded into caches
from version 1 of the zone can still be verified with
key sets fetched from version 2 of the zone.
The minimum time that the key set including DNSKEY 10
is to be published is the time that it takes for
zone data from the previous version of the zone to
expire from old caches, i.e., the time it takes for
this zone to propagate to all authoritative servers
plus the Maximum Zone TTL value of any of the data
in the previous version of the zone.
DNSKEY 10 is removed from the
zone. The key set, now only containing DNSKEY 1 and
DNSKEY 11, is re-signed with the DNSKEY 1.
The above scheme can be simplified by always
publishing the "future" key immediately after the rollover.
The scheme would look as follows (we show two rollovers); the
future key is introduced in "new DNSKEY" as DNSKEY 12 and again
a newer one, numbered 13, in "new DNSKEY (II)":
Note that the key introduced in the "new DNSKEY" phase is not
used for production yet; the private key can thus be
stored in a physically secure manner and does not need to
be 'fetched' every time a zone needs to be signed.
This section shows how to perform a ZSK key rollover
using the double zone data signature scheme, aptly named
"double signature rollover".
During the "new DNSKEY" stage the new version of the zone
file will need to propagate to all authoritative servers
and the data that exists in (distant) caches will need to
expire, requiring at least the Maximum Zone TTL.
Initial Version
of the zone: DNSKEY 1 is the Key Signing Key. DNSKEY 10 is used
to sign all the data of the zone, the
Zone Signing Key.
At the "New DNSKEY" stage (SOA serial
1) DNSKEY 11 is introduced into the key set and all the
data in the zone is signed with DNSKEY 10 and DNSKEY
11. The rollover period will need to continue until all
data from version 0 of the zone has expired from
remote caches. This will take at least the Maximum
Zone TTL of version 0 of the zone.
DNSKEY 10 is removed from the
zone. All the signatures from DNSKEY 10 are removed from
the zone. The key set, now only containing DNSKEY 11, is
re-signed with DNSKEY 1. At every instance, RRSIGs from the previous version of
the zone can be verified with the DNSKEY RRSet from the
current version and the other way around. The data from
the current version can be verified with the data from the
previous version of the zone. The duration of the "new DNSKEY"
phase and the period between rollovers should be at least
the Maximum Zone TTL.
Making sure that the "new DNSKEY" phase lasts until the
signature expiration time of the data in the initial version of the
zone is recommended. This way all caches are cleared of the old
signatures. However, this duration could be
considerably longer than the Maximum Zone TTL, making the
rollover a lengthy procedure.
Note that in this example we assumed that the zone was
not modified during the rollover. New data can be
introduced in the zone as long as it is signed with both
keys.
This rollover does not involve signing the zone data
twice. Instead, before the actual rollover, the
new key is published in the key set and thus is
available for cryptanalysis attacks. A small
disadvantage is that this process requires four
steps. Also the pre-publish scheme involves more
parental work when used for KSK rollovers as
explained in .
The drawback of this signing scheme is that during the
rollover the number of signatures in your zone doubles;
this may be prohibitive if you have very big zones. An
advantage is that it only requires three steps.
For the rollover of a Key Signing Key, the same
considerations as for the rollover of a Zone Signing Key
apply. However, we can use a double signature scheme
to guarantee that old data (only the apex key set) in
caches can be verified with a new key set and vice versa.
Since only the key set is signed with a KSK, zone size considerations
do not apply.
Initial version
of the zone. The parental DS points to DNSKEY1. Before
the rollover starts, the child will have to verify what the
TTL is of the DS RR that points to DNSKEY1 -- it is needed
during the rollover and we refer to the value as TTL_DS.
During the
"new DNSKEY" phase, the zone administrator generates a second
KSK, DNSKEY2. The key is provided to the parent, and the
child will have to wait until a new DS RR has been
generated that points to DNSKEY2. After that DS RR has
been published on all servers authoritative for the
parent's zone, the zone administrator has to wait at least
TTL_DS to make sure that the old DS RR has expired from
caches.
The parent replaces DS1 with
DS2.
DNSKEY1 has been
removed.
The scenario above puts the responsibility for
maintaining a valid chain of trust with the child. It also
is based on the premise that the parent only has one DS RR
(per algorithm) per zone. An alternative mechanism has been
considered. Using an established trust relation, the
interaction can be performed in-band, and the removal of
the keys by the child can possibly be signaled by the parent. In
this mechanism, there are periods where there are two DS RRs
at the parent. Since at the moment of writing the protocol
for this interaction has not been developed, further discussion
is out of scope for this document.
Note that KSK rollovers and ZSK rollovers are different in the
sense that a KSK rollover requires interaction with the parent (and
possibly replacing of trust anchors) and the ensuing delay while waiting
for it.
A zone key
rollover can be handled in two different ways: pre-publish () and double signature ().
As the KSK is used to validate the key set and because the
KSK is not changed during a ZSK rollover, a cache is able to
validate the new key set of the zone. The pre-publish
method would also work for a KSK rollover. The records that are to
be pre-published are the parental DS RRs.
The pre-publish method has some drawbacks for KSKs. We first describe the
rollover scheme and then indicate these drawbacks.
When the child zone wants to roll, it notifies the
parent during the "new DS" phase and submits the new key (or
the corresponding DS) to the parent.
The parent publishes DS1 and DS2, pointing to
DNSKEY1 and DNSKEY2, respectively. During the rollover ("new DNSKEY"
phase), which
can take place as soon as the new DS set propagated through
the DNS, the child replaces DNSKEY1 with
DNSKEY2. Immediately after that ("DS/DNSKEY removal" phase),
it can notify the parent that the old DS record can be deleted.
The drawbacks of this scheme are that during the
"new DS" phase the parent cannot verify the match between the
DS2 RR and DNSKEY2 using the DNS -- as DNSKEY2 is not
yet published. Besides, we introduce a
"security lame" key (see ). Finally, the
child-parent interaction consists of two steps. The "double
signature" method only needs one interaction.
[OK: The txt of this section is a strawman for the issue in:
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll
]
A special class of keyrollover is the rollover of key
algorithms (either adding a new algorithm, removing an old
algorithm, or both), additional steps are needed to retain
integrity during the rollover.
Because of the algorithm downgrade protection in RFC4035
section 2.2, you may not have a key of an algorithm for which
you do not have signatures.
When adding a new algorithm, the signatures should be added
first. After the TTL has expired, and caches have dropped the
old data covered by those signatures, the DNSKEY with the new
algorithm can be added. When removing an old algorithm, the
DNSKEY should be removed first.
To do both, the following steps can be used. For simplicity, we use a
zone that is only signed by one zone signing key.
In step 2, the signatures for the new key are added, but the key itself
is not. While in theory, the signatures of the keyset should always be
synchronized with the keyset itself, it can be possible that RRSIGS are
requested separately, so it might be prudent to also sign the DNSKEY
set with the new signature.
After the cache data has expired, the new key can be added to the zone,
as done in step 3.
The next step is to remove the old algorithm. This time the key needs
to be removed first, before removing the signatures. The key is removed
in step 4, and after the cache data has expired, the signatures can be
removed in step 5.
The above steps ensure that during the rollover to a new algorithm,
the integrity of the zone is never broken.
As keys must be renewed periodically, there is some motivation to
automate the rollover process. Consider the following:
ZSK rollovers are easy to automate as only the child zone is involved.
A KSK rollover needs interaction between parent and child.
Data exchange is needed to provide the new keys to the parent; consequently,
this data must be authenticated and integrity must be guaranteed in order to avoid
attacks on the rollover.
This section deals with preparation for a possible key
compromise. Our advice is to have a documented procedure ready
for when a key compromise is suspected or confirmed.
When the private material of one of your keys is
compromised it can be used for as long as a valid
trust chain exists. A trust chain remains
intact for
as long as a signature over the compromised key
in the trust chain is valid,
as long as a parental DS RR (and signature) points to
the compromised key,
as long as the key is anchored in a resolver and is
used as a starting point for validation (this is generally the hardest
to update).
While a trust chain to your compromised key
exists, your namespace is vulnerable to abuse by anyone who
has obtained illegitimate possession of the key. Zone
operators have to make a trade-off if the abuse of the
compromised key is worse than having data in caches that
cannot be validated. If the zone operator chooses to break
the trust chain to the compromised key, data in
caches signed with this key cannot be validated. However, if
the zone administrator chooses to take the path of a regular
rollover, the malicious key holder can spoof data so that
it appears to be valid.
A zone containing a DNSKEY RRSet with a compromised KSK
is vulnerable as long as the compromised KSK is configured as
trust anchor or a parental DS points to it. A compromised KSK can be used to sign the key set of an
attacker's zone. That zone could be used to poison
the DNS.
Therefore, when the KSK has been compromised, the trust anchor
or the parental DS should be replaced as soon as
possible. It is local policy whether to break the
trust chain during the emergency rollover. The
trust chain would be broken when the compromised
KSK is removed from the child's zone
while the parent still has a DS pointing to the compromised
KSK (the assumption is that there is only one DS at the
parent. If there are multiple DSes this does not apply -- however
the chain of trust of this particular key is broken). Note that an attacker's zone still uses the compromised KSK and the presence
of a parental DS would cause the data in this zone
to appear as valid. Removing the compromised key would cause
the attacker's zone to appear as valid and the child's zone as
Bogus. Therefore, we advise not to remove the KSK before the
parent has a DS to a new KSK in place. If we follow this advice, the timing of the replacement of
the KSK is somewhat critical. The goal is to remove the
compromised KSK as soon as the new DS RR is available at the
parent. And also make sure that the signature made with a new
KSK over the key set with the compromised KSK in it expires
just after the new DS appears at the parent, thus removing
the old cruft in one swoop.
The procedure is as follows:
Introduce a new KSK into the key set, keep the
compromised KSK in the key set.Sign the key set, with a short validity period. The
validity period should expire shortly after the DS is
expected to appear in the parent and the old DSes have
expired from caches.Upload the DS for this new key to the parent.Follow the procedure of the regular KSK rollover: Wait
for the DS to appear in the authoritative servers and then
wait as long as the TTL of the old DS RRs. If necessary
re-sign the DNSKEY RRSet and modify/extend the expiration time. Remove the compromised
DNSKEY RR from the zone and re-sign the key set using your
"normal" validity interval.
An additional danger of a key compromise is that the
compromised key could be used to facilitate a legitimate
DNSKEY/DS rollover and/or nameserver changes at the parent. When
that happens, the domain may be in dispute. An
authenticated out-of-band and secure notify mechanism to
contact a parent is needed in this case.
Note that this is only a problem when the DNSKEY and or
DS records are used for authentication at the parent.
There are two methods to break the chain of trust. The first method causes the
child zone to appear 'Bogus' to validating resolvers. The other
causes the child zone to appear 'insecure'. These are described below.
In the method that causes the child zone to appear 'Bogus' to
validating resolvers,
the child zone
replaces the current KSK with a new one and re-signs the key set.
Next it sends the DS of the new key to the parent. Only after the
parent has placed the new DS in the zone is the child's chain of
trust repaired.
An alternative method of breaking the chain of trust is by
removing the DS RRs from the parent zone altogether. As a result, the
child zone would become insecure.
Primarily because there is no parental interaction
required when a ZSK is compromised, the situation is less
severe than with a KSK compromise. The zone must still
be re-signed with a new ZSK as soon as possible. As this is a
local operation and requires no communication between the
parent and child, this can be achieved fairly
quickly. However, one has to take into account that just as
with a normal rollover the immediate disappearance of the
old compromised key may lead to verification problems.
Also note that as long as the RRSIG
over the compromised ZSK is not expired the zone may be still at
risk.
A key can also be pre-configured in resolvers. For
instance, if DNSSEC is successfully deployed the root key
may be pre-configured in most security aware
resolvers.
If trust-anchor keys are compromised, the resolvers
using these keys should be notified of this fact. Zone
administrators may consider setting up a mailing list to
communicate the fact that a SEP key is about to be rolled
over. This communication will of course need to be
authenticated, e.g., by using digital signatures.
End-users faced with the task of updating an anchored key
should always validate the new key. New keys should be
authenticated out-of-band, for example, through the use of
an announcement website that is secured using secure
sockets (TLS) .
The initial key exchange is always subject to the policies
set by the parent. When designing a key
exchange policy one should take into account that the
authentication and authorization mechanisms used during a key
exchange should be as strong as the authentication and
authorization mechanisms used for the exchange of delegation
information between parent and child. That is, there is no implicit
need in DNSSEC to make the authentication process stronger than it was
in DNS. Using the DNS itself as the source for the actual DNSKEY
material, with an out-of-band check on the validity of the
DNSKEY, has the benefit that it reduces the chances of user
error. A DNSKEY query tool can make use of the
SEP bit to select the proper
key from a DNSSEC key set, thereby reducing the chance that
the wrong DNSKEY is sent. It can validate the self-signature
over a key; thereby verifying the ownership of the private
key material. Fetching the DNSKEY from the DNS ensures that
the chain of trust remains intact once the parent publishes
the DS RR indicating the child is secure. Note: the out-of-band verification is still needed when the
key material is fetched via the DNS. The parent can never be
sure whether or not the DNSKEY RRs have been spoofed.
When designing a registry system one should consider
which of the DNSKEYs and/or the corresponding DSes to store.
Since a child zone might wish to have a DS published using a
message digest algorithm not yet understood by the registry,
the registry can't count on being able to generate the DS
record from a raw DNSKEY. Thus, we recommend that registry
systems at least support storing DS records.
It may also be useful to store DNSKEYs, since having
them may help during troubleshooting and, as long as the
child's chosen message digest is supported, the overhead of
generating DS records from them is minimal. Having an
out-of-band mechanism, such as a registry directory (e.g., Whois),
to find out which keys are used to generate DS Resource Records for
specific owners and/or zones may also help with
troubleshooting.
The storage considerations also relate to the design of
the customer interface and the method by which data is
transferred between registrant and registry; Will the child
zone administrator be able to upload DS RRs with unknown
hash algorithms or does the interface only allow DNSKEYs? In
the registry-registrar model, one can use the DNSSEC
extensions to the Extensible Provisioning Protocol (EPP)
, which allows transfer of DS RRs
and optionally DNSKEY RRs.
Security lameness is defined as what happens when a
parent has a DS RR pointing to a non-existing
DNSKEY RR. When this happens, the child's zone may be marked
"Bogus" by verifying DNS clients.
As part of a comprehensive delegation check, the parent could,
at key exchange time, verify that the child's key is actually
configured in the DNS.
However, if a parent does not understand the hashing algorithm used
by child, the parental checks are limited to only comparing the key
id.
Child zones should be very careful in removing DNSKEY material,
specifically SEP keys, for which a DS RR exists.
Once a zone is "security lame", a fix (e.g., removing a
DS RR) will take time to propagate through the DNS.
Since the DS can be replayed as long as it has a valid
signature, a short signature validity period over the DS
minimizes the time a child is vulnerable in the case of a
compromise of the child's KSK(s). A signature validity
period that is too short introduces the possibility that a
zone is marked "Bogus" in case of a configuration error in the
signer. There may not be enough time to fix the problems
before signatures expire. Something as mundane as operator
unavailability during weekends shows the need for DS
signature validity periods longer than 2 days. We recommend an
absolute minimum for a DS signature validity period of a few days.
The maximum signature validity period of the DS record depends on
how long child zones are willing to be vulnerable after a key compromise. On
the other hand, shortening the DS signature validity interval increases the
operational risk for the parent. Therefore, the parent may have policy to use
a signature validity interval that is considerably longer than the child would
hope for.
A compromise between the operational constraints of the parent
and minimizing damage for the child may result in a DS signature
validity period somewhere between a week and months.
In addition to the signature validity period, which sets a lower
bound on the number of times the zone owner will need to sign the
zone data and which sets an upper bound to the time a child is
vulnerable after key compromise, there is the TTL value on the DS
RRs. Shortening the TTL means that the authoritative servers will see more
queries. But on the other hand, a short TTL lowers the persistence of
DS RRSets in caches thereby increasing the speed with which updated DS
RRSets propagate through the DNS.
[OK: this is a first strawman, and is intended to start
the discussion of the issue. By no means this is intended
to be a final text.]
The parent-child relation is often described in terms of a
(thin) registry model. Where a registry maintains the
parent zone, and the registrant (the user of the
child-domain name), deals with the registry through an
intermediary called a registrar. (See for a comprehensive
definition). Registrants may out-source the maintenance of
their DNS system, including the maintenance of DNSSEC key
material, to the registrar or to another third party. The
entity that has control over the DNS zone and its keys may
prevent the registrant to make a timely move to a
different registrar. [OK: I use the term registrar below
while it is the operator of the DNS zone who is the actual
culprit. For instance, the case also applies when a
registrant passes a zone to another registrant. Should I
just use "DNS Administrator"?]
Suppose that the registrant wants to move from losing
registrar A to gaining registrar B. Let us first look
what would happen in a cooperative environment. The
assumption is that registrar A will not hand off any
private key material to registrar B because that would be
a trivial case.
In a cooperating environment one could proceed with a
pre-publish ZSK rollover whereby registrar A pre-publishes
the ZSK of registrar B, combined with a double signature
KSK rollover where the two registrars exchange public keys
and independently generate a signature over the keysets
that they combine and both publish in the zone.
In the non-cooperative case matters are more
complicated. The loosing registrar A may not cooperate and
leave the data in the DNS as is. In the extreme case
registrar A may become obstructive and publish a DNSKEY RR
with a high TTL and corresponding signature validity so
that registrar A's DNSKEY, would end up in caches for, in
theory, tens of years.
The problem arises when a validator tries to validate with
A's key and there is no signature material produced with
Registrars A available in the delegation path after
redelegation from registrar A to registrar B has taken
place. One could imagine a rollover scenario where
registrar B pulls all RRSIGs created by registar A and
publishes those in conjunction with its own signatures,
but that would not allow any changes in the zone
content. Since a redelegation took place the NS RRset has
-- per definition-- changed so such rollover scenario will
not work. Besides if zone transfers are not allowed by A
and NSEC3 is deployed in the A's zone then registrar B
will not have certainty that all of A's RRSIGs are
transfered.
The only viable option for the registrant is to publish
its zone unsigned and ask the registry to remove the DS
pointing to registrar A for as long as the DNSKEY of
registrar A, or any of the signatures produced by
registrar A are likely to appear in caches, which as
mentioned above could in theory be for tens of years.
[OK: Some implementations limit the time data is
cached. Although that is not a protocol requirement (and
may even be considered a protocol violation) it seems that
that practice may limit the impact of this problem, is
that worth mentioning?]
[OK: This is really the point that I'm trying to make, is
the above text needed?] There is no operational
methodology to work around this business issue and proper
contractual relations ships between registrants and their
registrars seem to be the only solution to cope with these
problems.
DNSSEC adds data integrity to the DNS. This document tries
to assess the operational considerations to maintain a stable
and secure DNSSEC service. Not taking into account the 'data
propagation' properties in the DNS will cause validation
failures and may make secured zones unavailable to
security-aware resolvers. There are no IANA considerations with respect to this documentMost of the text of this document is copied from RFC4641 people involved in that work
were in random order: Rip Loomis, Olafur Gudmundsson, Wesley
Griffin, Michael Richardson, Scott Rose, Rick van Rein, Tim
McGinnis, Gilles Guette Olivier Courtay, Sam Weiler, Jelte
Jansen, Niall O'Reilly, Holger Zuleger, Ed Lewis, Hilarie
Orman, Marcos Sanz, Peter Koch, Mike StJohns, Emmar
Bretherick, Adrian Bedford, and Lindy Foster, G. Guette, and
O. Courtay.
For this version of the document we would like to acknowldge:
Paul Hoffman for his contribution on the choice of
cryptographic paramenters and addressing some of the trust
anchor issues. Jelte Jansen provided the text in Domain names - concepts and facilitiesInformation Sciences Institute (ISI)Domain names - implementation and specificationUSC/ISI4676 Admiralty WayMarina del ReyCA90291US+1 213 822 1511DNS Security Introduction and RequirementsThe Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS TRACK]Resource Records for the DNS Security ExtensionsThis document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.</t><t> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS TRACK]Protocol Modifications for the DNS Security ExtensionsThis document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.</t><t> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS TRACK]Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
Incremental Zone Transfer in DNSComputer Center Tokyo Institute of Technology2-12-1, O-okayamaMeguro-kuTokyo152JP+81 3 57343299+81 3 57343415mohta@necom830.hpcl.titech.ac.jpThis document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism.A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)Internet Software ConsortiumStar Route Box 159AWoodsideCA94062US+1 415 747 0204paul@vix.comThis memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data.Negative Caching of DNS Queries (DNS NCACHE)CSIRO - Mathematical and Information SciencesLocked Bag 17North Ryde NSW 2113AUSTRALIA+61 2 9325 3148Mark.Andrews@cmis.csiro.au
Applications
domain name systemDNS
[RFC1034] provided a description of how to cache negative responses.
It however had a fundamental flaw in that it did not allow a name
server to hand out those cached responses to other resolvers, thereby
greatly reducing the effect of the caching. This document addresses
issues raise in the light of experience and replaces [RFC1034 Section
4.3.4].
Negative caching was an optional part of the DNS specification and
deals with the caching of the non-existence of an RRset [RFC2181] or
domain name.
Negative caching is useful as it reduces the response time for
negative answers. It also reduces the number of messages that have
to be sent between resolvers and name servers hence overall network
traffic. A large proportion of DNS traffic on the Internet could be
eliminated if all resolvers implemented negative caching. With this
in mind negative caching should no longer be seen as an optional part
of a DNS resolver.
DNS Security Operational ConsiderationsIBM65 Shindegan Hill RoadRR #1CarmelNY10512US+1 914 276 2668+1 914 784 3833dee3@us.ibm.comSecure DNS is based on cryptographic techniques. A necessary part of the strength of these techniques is careful attention to the operational aspects of key and signature generation, lifetime, size, and storage. In addition, special attention must be paid to the security of the high level zones, particularly the root zone. This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records.Secure Domain Name System (DNS) Dynamic UpdateThis document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS TRACK]Generic Registry-Registrar Protocol RequirementsDetermining Strengths For Public Keys Used For Exchanging Symmetric KeysImplementors of systems that use public key cryptography to exchange symmetric keys need to make the public keys resistant to some predetermined level of attack. That level of attack resistance is the strength of the system, and the symmetric keys that are exchanged must be at least as strong as the system strength requirements. The three quantities, system strength, symmetric key strength, and public key strength, must be consistently matched for any network protocol usage. While it is fairly easy to express the system strength requirements in terms of a symmetric key length and to choose a cipher that has a key length equal to or exceeding that requirement, it is harder to choose a public key that has a cryptographic strength meeting a symmetric key strength requirement. This document explains how to determine the length of an asymmetric key as a function of a symmetric key strength requirement. Some rules of thumb for estimating equivalent resistance to large-scale attacks on various algorithms are given. The document also addresses how changing the sizes of the underlying large integers (moduli, group sizes, exponents, and so on) changes the time to use the algorithms for key exchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Randomness Requirements for SecuritySecurity systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t><t> Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security extensions (DNSSEC) for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. [STANDARDS TRACK]DNSSEC Operational PracticesThis document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.</t><t> The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.</t><t> This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. This memo provides information for the Internet community.Internet Security Glossary, Version 2This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.Automated Updates of DNS Security (DNSSEC) Trust AnchorsThis document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).</t><t> This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS TRACK]NIST DNSSEC workshop notes
Recommendation for Random Number Generation Using
Deterministic Random Bit Generators (Revised)
Computer Security Division, Information Technology Laboratory
Computer Security Division, Information Technology Laboratory
Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSECThis document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone. [STANDARDS TRACK]Transport Layer Security (TLS) ExtensionsThis document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.</t><t> The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. [STANDARDS TRACK] In this document, there is some jargon used that is defined
in other documents. In most cases, we have not copied the text
from the documents defining the terms but have given a more elaborate
explanation of the meaning. Note that these explanations should not be
seen as authoritative.
A DNSKEY configured in resolvers around the globe. This key
is hard to update, hence the term anchored.
Also see Section
5 of. An RRSet in DNSSEC is marked "Bogus" when a
signature of an RRSet does not validate against a DNSKEY.
A Key Signing Key (KSK) is a key that is used exclusively for
signing the apex key set. The fact that a key is a KSK is
only relevant to the signing tool.
The term 'key size' can be substituted by 'modulus size'
throughout the document. It is mathematically more correct to
use modulus size, but as this is a document directed at
operators we feel more at ease with the term key size.
DNSSEC secures the DNS through the use of public key
cryptography. Public key cryptography is based on the
existence of two (mathematically related) keys, a public key
and a private key. The
public keys are published in the DNS by use of the DNSKEY
Resource Record (DNSKEY RR). Private keys should
remain private.
A key rollover (also called key supercession in some
environments) is the act of replacing one key pair with
another at the end of a key effectivity period.
A KSK that has a parental DS record pointing to it or is
configured as a trust anchor. Although not required
by the protocol, we recommend that the SEP flag
is set on these keys.
This only applies to signatures over DNSKEYs; a signature
made with DNSKEY x, over DNSKEY x is called a self-signature.
Note: without further information, self-signatures convey no
trust. They are useful to check the authenticity of the DNSKEY,
i.e., they can be used as a hash.
The term used for the event where an administrator joyfully
signs its zone file while producing melodic sound patterns.
The system that has access to the private key material and
signs the Resource Record sets in a zone. A signer may be
configured to sign only parts of the zone, e.g., only those
RRSets for which existing signatures are about to expire.
A key that is used for signing all data in a zone
(except, perhaps, the DNSKEY RRSet). The fact that a
key is a ZSK is only relevant to the signing tool.
The 'role' that is responsible for signing a zone and
publishing it on the primary authoritative server.
Using the pre-published signature scheme and the most
conservative method to assure oneself that data does not
live in caches, here follows the "how-to".
The preparation: Create two keys and publish both in
your key set. Mark one of the keys "active" and the
other "published". Use the "active" key for signing your
zone data. Store the private part of the "published"
key, preferably off-line. The protocol does not provide
for attributes to mark a key as active or
published. This is something you have to do on your own,
through the use of a notebook or key management tool.
Determine expiration: At the beginning of the
rollover make a note of the highest expiration time of
signatures in your zone file created with the current key
marked as active.
Wait until the expiration time marked in Step 1 has passed.
Then start using the key that was marked
"published" to sign your data (i.e., mark it
"active"). Stop using the key that was marked
"active"; mark it "rolled".
It is safe to engage in a new rollover (Step
1) after at least one signature validity period.
The following typographic conventions are used in this document:
A key is denoted by DNSKEYx, where x is a number or an
identifier, x could be thought of as the key id.
RRs are only denoted by the type. All other information
-- owner, class, rdata, and TTL -- is left out. Thus:
"example.com 3600 IN A 192.0.2.1" is reduced to
"A". RRSets are a list of RRs. A example of this would
be "A1, A2", specifying the RRSet containing two "A"
records. This could again be abbreviated to just "A".
Signatures are denoted as RRSIGx(RRSet), which means
that RRSet is signed with DNSKEYx.
Using the above notation we have simplified the
representation of a signed zone by leaving out all
unnecessary details such as the names and by
representing all data by "SOAx"
SOAs are represented as SOAx, where x is the serial
number.
Using this notation the following signed zone:
is reduced to the following representation:
The rest of the zone data has the same signature as the SOA
record, i.e., an RRSIG created with DNSKEY 14.
[To be removed prior to publication as an RFC]
Version 0 was differs from RFC4641 in the following ways.
Status of this memo appropriate for I-D
TOC formatting differs.
Whitespaces, linebreaks, and pagebreaks may be slightly different
because of xml2rfc generation.
References slightly reordered.
Applied the errata from
http://www.rfc-editor.org/errata_search.php?rfc=4641
Inserted trivial "IANA considertations" section.
In other words it should not contain substantive changes in
content as intended by the workinggroup for the original RFC4641.
Cryptography details rewritten.
(See http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/cryptography_flawed)
Reference to NIST 800-90 addedRSA/SHA256 is being recommended in addition to RSA/SHA1. Complete rewrite of
removing the table and suggesting a keysize of 1024 for
keys in use for less than 8 years, issued up to at least
2015. Replaced the reference to Schneiers' applied cryptograpy with a reference to RFC4949.
Removed the KSK for high level zones consideration
Applied some differentiation with respect of the use of a
KSK for parent or trust-anchor relation
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/differentiation_trustanchor_parent
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/rollover_assumptions
Added as suggested by Jelte Jansen
in
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll
Added
Issue identified by Antoin Verschuur
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/non-cooperative-registrars
In : ZSK does not nescessarily sign the DNSKEY RRset.$Id: draft-ietf-dnsop-rfc4641bis-01.xml 28 2009-03-06 14:03:57Z olaf $