Internet DRAFT - draft-fanf-dnsop-sha-ll-not
draft-fanf-dnsop-sha-ll-not
DNS Operations T. Finch
Internet-Draft University of Cambridge
Updates: 8624 (if approved) March 9, 2020
Intended status: Standards Track
Expires: September 10, 2020
Hardening DNSSEC against collision weaknesses in SHA-1 and other
cryptographic hash algorithms
draft-fanf-dnsop-sha-ll-not-00
Abstract
DNSSEC deployments have often used the SHA-1 cryptographic hash
algorithm to provide authentication of DNS data. This document
explains why SHA-1 is no longer secure for this purpose, and
deprecates its use in DNSSEC signatures. This document updates RFC
8624.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 10, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Finch Expires September 10, 2020 [Page 1]
Internet-Draft DNSSEC vs collision attacks March 2020
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Deprecating SHA-1 in DNSSEC . . . . . . . . . . . . . . . . . 3
2.1. DNSSEC signing software . . . . . . . . . . . . . . . . . 4
2.2. DNS hosting services . . . . . . . . . . . . . . . . . . 4
2.3. DNSSEC validating software . . . . . . . . . . . . . . . 4
2.4. DNS resolver services . . . . . . . . . . . . . . . . . . 5
3. Collision attacks against DNSSEC . . . . . . . . . . . . . . 5
3.1. Chosen-prefix collisions . . . . . . . . . . . . . . . . 5
3.2. Collision attacks and signatures . . . . . . . . . . . . 5
3.3. Breaking DNSSEC . . . . . . . . . . . . . . . . . . . . . 6
3.4. Collision attacks and RRSIG records . . . . . . . . . . . 6
4. Hardening RRSIG records . . . . . . . . . . . . . . . . . . . 7
4.1. Predicting inception and expiration times . . . . . . . . 8
4.2. Unpredictable X.509 certificates . . . . . . . . . . . . 8
4.3. Less predictable RRSIG records . . . . . . . . . . . . . 9
5. Collision attacks and other DNS record types . . . . . . . . 9
5.1. TXT records . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Syntax of TXT records . . . . . . . . . . . . . . . . 10
5.1.2. Mitigating TXT record attacks . . . . . . . . . . . . 10
5.2. CAA records . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. SSHFP records . . . . . . . . . . . . . . . . . . . . . . 11
5.4. DNSKEY records . . . . . . . . . . . . . . . . . . . . . 11
5.4.1. Shared keys . . . . . . . . . . . . . . . . . . . . . 11
5.4.2. Combined signing keys . . . . . . . . . . . . . . . . 11
5.5. DS records . . . . . . . . . . . . . . . . . . . . . . . 12
6. Other uses of SHA-1 in the DNS . . . . . . . . . . . . . . . 12
6.1. DS and CDS records . . . . . . . . . . . . . . . . . . . 12
6.2. NSEC3 records . . . . . . . . . . . . . . . . . . . . . . 13
6.3. SSHFP records . . . . . . . . . . . . . . . . . . . . . . 13
6.4. TSIG authentication . . . . . . . . . . . . . . . . . . . 13
7. Security considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Staying secure . . . . . . . . . . . . . . . . . . . . . 14
7.2. When to declare SHA-1 insecure . . . . . . . . . . . . . 14
7.3. Avoiding unwanted insecurity . . . . . . . . . . . . . . 14
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 18
Appendix B. Timeline . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
Finch Expires September 10, 2020 [Page 2]
Internet-Draft DNSSEC vs collision attacks March 2020
1. Introduction
Since 2005, SHA-1 has been known to be much weaker than it was
designed to be. Over the last 5 years there has been a series of
increasingly powerful demonstrations that SHA-1's weaknesses can be
exploited in practice. In January 2020, Gaetan Leurent and Thomas
Peyrin announced a chosen-prefix collision for SHA-1 [SHA-mbles].
This was the first practical break of SHA-1 as used in cryptographic
signatures.
DNSSEC uses cryptographic signatures to authenticate DNS data. Its
signature algorithms [DNSKEY-IANA] include RSASHA1 (5) and
RSASHA1-NSEC3-SHA1 (7) which are vulnerable to chosen-prefix
collisions in SHA-1, as described in Section 3. This document
deprecates these vulnerable algorithms (Section 2).
SHA-1 has been deprecated in other situations for several years (see
Appendix B). This document's timetable for deprecating SHA-1 in
DNSSEC (Section 2) is based on those examples, adapted for the
particulars of the DNS. Section 7 discusses the trade-offs between
speedy deprecation and security.
A collision attack can be used against DNSSEC in a number of ways,
some of which are explored in Section 5. Certain weaknesses in the
way DNSSEC is sometimes deployed can make collision attacks easier to
carry out, or make their consequences more severe. Although the only
sure way to protect against collision attacks is to use a secure
algorithm (Section 2), Section 4 and Section 5 outline some partial
mitigations.
The DNS uses SHA-1 for a number of other less vulnerable purposes, as
outlined in section Section 6.
1.1. Terminology
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 [RFC2119].
2. Deprecating SHA-1 in DNSSEC
The following table lists the implementation recommendations for
DNSKEY algorithms [DNSKEY-IANA]. The change from [RFC8624] section
3.1 is to deprecate algorithms 5 and 7.
Finch Expires September 10, 2020 [Page 3]
Internet-Draft DNSSEC vs collision attacks March 2020
+-----+--------------------+-----------------+---------------------+
| No. | Mnemonic | DNSSEC Signing | DNSSEC Validation |
+-----+--------------------+-----------------+---------------------+
| 1 | RSAMD5 | MUST NOT | MUST NOT |
| 3 | DSA | MUST NOT | MUST NOT |
| 5 | RSASHA1 | MUST NOT | MUST NOT after 2021 |
| 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT |
| 7 | RSASHA1-NSEC3-SHA1 | MUST NOT | MUST NOT after 2021 |
| 8 | RSASHA256 | MUST | MUST |
| 10 | RSASHA512 | NOT RECOMMENDED | MUST |
| 12 | ECC-GOST | MUST NOT | MAY |
| 13 | ECDSAP256SHA256 | MUST | MUST |
| 14 | ECDSAP384SHA384 | MAY | RECOMMENDED |
| 15 | ED25519 | RECOMMENDED | RECOMMENDED |
| 16 | ED448 | MAY | RECOMMENDED |
+-----+--------------------+-----------------+---------------------+
The following subsections have recommended timelines for deprecating
algorithms 5 and 7 in specific situations.
2.1. DNSSEC signing software
DNSSEC key management and zone signing software MUST remove support
for algorithms 5 and 7 in their next feature release.
2.2. DNS hosting services
Authoritative DNS hosting services that include DNSSEC signing as
part of the service SHOULD NOT generate a new key with algorithms 5
or 7 for a zone that does not already have a key with the same
algorithm. They MUST NOT do so after the end of 2020.
Zones signed with algorithms 5 or 7 SHOULD be rolled over to a
mandatory algorithm (13 or 8) as soon as possible. The rollovers
MUST be complete before the end of 2021.
2.3. DNSSEC validating software
Validating resolvers SHOULD have a build-time or run-time option to
disable selected DNSKEY algorithms, that is, to treat them as unknown
or insecure.
Algorithms 5 and 7 MUST be disabled in 2022 at the latest. If SHA-1
becomes significantly weaker before then, Algorithms 5 and 7 MUST be
disabled in a security patch release.
Finch Expires September 10, 2020 [Page 4]
Internet-Draft DNSSEC vs collision attacks March 2020
2.4. DNS resolver services
Validating resolvers MUST treat algorithms 5 and 7 as unknown or
insecure after the start of 2022, or earlier if SHA-1 becomes
significantly weaker before then.
3. Collision attacks against DNSSEC
This section explains how collisions in cryptographic functions (such
as SHA-1) can be used to break DNSSEC data authentication. Section 5
has some more specific examples of how this break can be used to
mount attacks.
3.1. Chosen-prefix collisions
With hash functions like SHA-1, a chosen-prefix collision attack uses
two messages that have a structure like this:
+----------+-----------+--------+
message-1: | prefix-1 | collide-1 | suffix |
+----------+-----------+--------+
+----------+-----------+--------+
message-2: | prefix-2 | collide-2 | suffix |
+----------+-----------+--------+
The two prefixes are entirely under the attacker's control.
The collision blocks are calculated to make the hashes collide. They
look like binary junk and cannot be made to conform to any particular
syntax. The collision blocks are 588 bytes long in the best attack
on SHA-1 at the time of writing [SHA-mbles].
The messages may need a suffix so that they are syntactically valid,
but this must be the same in both messages.
3.2. Collision attacks and signatures
A signature algorithm like RSASHA1 takes a cryptographic hash of the
message (using SHA-1 in this case) and uses an asymmetric algorithm
(RSA in this case) to turn the hash into a signature.
If the hash function is vulnerable, like SHA-1, then an attacker can:
o construct two prefixes, one innocuous and one malicious;
o calculate collision blocks so the two messages have the same hash;
Finch Expires September 10, 2020 [Page 5]
Internet-Draft DNSSEC vs collision attacks March 2020
o submit the innocuous message to be signed by some authority;
o copy the signature from the innocious message to the malicious
message;
o use the signed malicious message to perform attacks that would not
be possible without it.
The copied signature works on both the innocuous and malicious
messages because their hashes match.
It is usually less easy than this, because in most protocols part of
the innocuous message is chosen by the signer, so the attacker needs
to predict how the signer will work.
3.3. Breaking DNSSEC
To use a collision attack against DNSSEC, the innoccuous and
malicious messages are DNS RRsets.
DNSSEC provides strong authentication for DNS data. Within the DNS,
it prevents spoofing attacks and cache poisoning attacks. For
applications that use the DNS, DNSSEC can provide strong
authentication for application identifiers, such as a host name and
associated public key or challenge/response. Breaking DNSSEC means
subverting this authentication.
If an attacker has even very limited access to update a DNS zone that
uses SHA-1 (algorithm 5 or 7), the attacker can use a collision
attack to gain control over other names in the same zone.
Our attacker is able to update the DNS for certain innoccuous
records. The zone owner signs the updated innoccuous records and
publishes the new records and RRSIG in the zone. The attacker can
then make a DNS query for the updated records, and copy the signature
field from the innoccuous RRSIG into the signature field of the
attacker's malicious RRSIG. The attacker can use the signed
malicious RRset as part of a DNS spoofing or cache poisoning attack.
Section 5 has some examples.
3.4. Collision attacks and RRSIG records
When the attacker calculates the collision blocks, there is a bit
more to the innoccuous and malicious messages than just the RRsets.
They need to be in the format used for constructing RRSIG records
specified in [RFC4034] section 3.1.8.1 and sketched in the diagram
below:
Finch Expires September 10, 2020 [Page 6]
Internet-Draft DNSSEC vs collision attacks March 2020
+------------------------------------+
| RRSIG RDATA |
+------------------------------------+
| NAME TYPE CLASS TTL RDLENGTH RDATA |
+------------------------------------+
| ... more records ... |
+------------------------------------+
| NAME TYPE CLASS TTL RDLENGTH ( |
| collision blocks ) |
+------------------------------------+
The RRSIG RDATA is controlled by the signer, and must be predicted by
the attacker. Section 4 discusses how easy it is to predict the
RRSIG RDATA fields.
The DNS records are under the attacker's control, with some
limitations:
o In the innoccuous records, the NAME and TYPE identify an RRset
that the attacker can update.
o In the malicious records, the NAME must be in a zone signed by the
same key as the innoccuous records.
o The innoccuous and malicious TYPEs do not need to be the same, but
they must both have RDATA fields that can accommodate the
collision blocks.
o The attacker needs to ensure the records containg the collision
blocks come last when the RRsets are sorted into canonical order.
o The innoccuous and malicious records do not have to be aligned
with each other, but they need to have the same total length.
4. Hardening RRSIG records
To perform a collision attack against DNSSEC, the attacker needs to
know the RRSIG RDATA fields that the zone owner will use when signing
the attacker's innoccuous records.
The RRSIG RDATA fields are specified in [RFC4034] section 3.1. They
are:
o Type covered: same as the TYPE of the innoccuous RRset.
o Algorithm: same as the algorithm of the zone's DNSKEY records,
which for a vulnerable zone will be 5 or 7.
Finch Expires September 10, 2020 [Page 7]
Internet-Draft DNSSEC vs collision attacks March 2020
o Labels: derived from the NAME of the innoccuous RRset.
o Original TTL: same as the TTL of the innoccuous RRset.
o Signature expiration: a time set by the signer.
o Signature inception: a time set by the signer.
o Key tag: obtained from one of the zone's DNSKEY records.
o Signer's name: the name of the zone's DNSKEY records.
We can see that all of these fields are known to the attacker, apart
from the inception and expiration times.
4.1. Predicting inception and expiration times
There are a number of common ways for DNSSEC signers to set signature
inception and expiration times:
o The times are known offsets from the moment a DNS update is
processed.
o The update time is rounded to a multiple of (for example) 24 hours
and the signature times are known offsets from that.
o The zone is signed on a known schedule and the times are derived
from that schedule.
So in many cases an attacker can predict all the RRSIG RDATA fields
with little difficulty.
4.2. Unpredictable X.509 certificates
(A brief diversion to provide some rationale for the next sub-
section.)
In 2008 a chosen-prefix collision attack against MD5 was used to
obtain an illegitimate CA certificate signed by a commercial CA
[ROGUE-CA]. A key part of this attack was to predict the serial
number and validity period assigned by the commercial CA to the
innocuous certificate so that its MD5 hash would collide with the
malicious rogue CA certificate.
Following this attack, certificate authorities started using random
serial numbers instead of sequential numbers. In 2016 the CA/Browser
forum baseline requirements were amended to increase the amount of
Finch Expires September 10, 2020 [Page 8]
Internet-Draft DNSSEC vs collision attacks March 2020
randomness required from 20 bits to 64 bits [CABforum2016]. This
extra hardening was in addition to deprecating SHA-1 [CABforum2014].
4.3. Less predictable RRSIG records
In addition to upgrading to a secure algorithm (Section 2), DNSSEC
signers can provide extra protection against possible collision
attacks by adding entropy to make RRSIG inception and expiration
times less predictable.
The inception time SHOULD include at least 12 bits of output from a
CSPRNG. (2^12 seconds is slightly more than an hour.) For example,
set the inception time to the signing time minus an hour minus the
entropy.
The expiration time SHOULD include output from a CSPRNG equivalent to
about 25% of the nominal validity period. For instance, 19 bits (6
days) if the validity period is 1 month, or 17 bits (1.5 days) if the
validity period is 1 week. For example, set the expiration time to
the signing time plus 75% of the validity period plus the entropy.
A signer SHOULD change its signature validity times frequently, for
example, different times for each RRset, or different times each
second. This is so that an attacker cannot observe the signer's
current validity period and perform a collision attack before the
period changes.
5. Collision attacks and other DNS record types
This section discusses how a SHA-1 collision attack can be used with
various DNS record types. For an RRtype to be suitable it needs to
have a large RDATA with basically no internal structure, to
accommodate the collision blocks, which are 588 bytes long in the
best attack on SHA-1 at the time of writing [SHA-mbles].
There are a number of weaknesses that make a collision attack easier
to carry out, or which make the consequences of an attack more
severe. This section describes some mitigations for these
weaknesses, but note that these mitigations do not prevent collision
attacks. The main defence is to upgrade zones to a secure algorithm
(Section 2) and in many cases that will be easier than the additional
mitigations outlined below.
5.1. TXT records
TXT records are an attractive vehicle for a collision attack.
Finch Expires September 10, 2020 [Page 9]
Internet-Draft DNSSEC vs collision attacks March 2020
Access to update TXT records might be granted to support things like
ACME dns-01 challenges [RFC8555], so they can be useful as an
attacker's innoccuous records.
As the target of an attacker's malicious records, TXT records have
several interesting functions that might be useful to an attacker,
including ACME [RFC8555], DKIM [RFC6376], SPF [RFC7208],
authorization to provision cloud services, etc.
5.1.1. Syntax of TXT records
A TXT record's RDATA contains a sequence of strings, each of which is
a length octet followed by up to 255 octets of data. A single string
is too small to accommodate SHA-1 collision blocks.
An attacker can cope with this difficulty by not worrying about how
the string lengths end up inside a collision block. At the end of
the block there will be some unpredictable length of string that
needs to be filled; the attacker can append 255 zero bytes, which
will fill the remainder of the unknown string. The excess zero bytes
will parse as a sequence of zero-length strings. Although the
unfilled string lengths may be different in the inoccuous and
malicious records, they are both fixed by an identical suffix of 255
zeroes.
5.1.2. Mitigating TXT record attacks
Some attacks might be prevented by imposing stricter requirements on
TXT records, since most practical uses do not put un-encoded binary
data in TXT records.
An authoritative server MAY reject TXT records in DNS UPDATEs and
zone files if the strings contain ASCII control characters or invalid
UTF-8. This strict checking SHOULD be configurable so that zone
owners can use unrestricted binary in TXT records if they wish.
5.2. CAA records
An attacker might want to spoof certificate authority authorization
records [RFC8659] in order to obtain an illegitimate X.509
certificate.
A CAA record contains tag and value strings. The length of the value
is unrestricted, which makes it easy to accommodate collision blocks.
To mitigate collision attacks on CAA records, the specifications for
CAA record syntax and how CAA records are processed by certificate
Finch Expires September 10, 2020 [Page 10]
Internet-Draft DNSSEC vs collision attacks March 2020
authorities could be tightened up to reject a CAA RRset unless it is
all printable ASCII.
5.3. SSHFP records
An SSHFP record contains a fingerprint of a server public key
[RFC4255]. They are attractive as the target of a spoofing attack.
Access to update SSHFP records might be granted so that servers can
register themselves in the DNS, so SSHFP records can be useful as an
attacker's innoccuous records.
The length of an SSHFP record is implied by its fingerprint type
field, but they can be used in collision attacks if the length is not
strictly checked, or if unknown fingerprint types are allowed.
Authoritative DNS servers MAY reject SSHFP records with unknown
fingerprint types or mismatched lengths in DNS UPDATEs and zone
files. SSH clients MAY reject an entire SSHFP RRset if any record
has a fingerprint longer than 64 bytes. (Assuming that fingerprints
longer than 512 bits do not make sense.)
5.4. DNSKEY records
There are a couple of DNSSEC key management models that can make the
consequences of a collision attack worse.
5.4.1. Shared keys
Normally each zone has its own DNSSEC keys, so a collision attack
only works when the attacker's inoccuous and malicious records are in
the same zone.
Some DNSSEC deployments share the same keys across multiple zones.
This allows an attacker to target names in any zone that uses the
same key. For example, if this is a multi-tenant hosting
environment, the attacker could sign up with their own domain and use
that to perform collision attacks against other customers on the same
platform.
DNS hosting services and DNSSEC signing software SHOULD NOT allow
keys to be shared between multiple zones.
5.4.2. Combined signing keys
The traditional DNSSEC setup has two keys for a zone: a key-signing
key (KSK) that is only used to sign the zone's DNSKEY RRset; and a
zone-signing key (ZSK) which signs the other records in the zone.
Finch Expires September 10, 2020 [Page 11]
Internet-Draft DNSSEC vs collision attacks March 2020
There is a simpler setup in which a zone has only one key: a combined
signing key (CSK) which signs all the records in the zone.
The DNSKEY RRset is a huge target in a zone that is vulnerable to
collision attacks: if the attacker can get their own public key into
a signed DNSKEY RRset then one successful collision attack can be
used to spoof any record in the zone.
In a zone with split ZSK/KSK, the DNSKEY RRset is only trusted if it
is signed by the KSK, but collision attacks can only obtain a RRset
signed by the ZSK.
In a zone with a CSK the attacker can obtain a malicious trusted
DNSKEY RRset using a collision attack.
DNS hosting services and DNSSEC signing software SHOULD encourage
split ZSK/KSK configurations.
5.5. DS records
Top-level domains are the most prominent example of zones that can be
updated by many different clients from mutually antagonistic
organizations.
TLDs are typically updated via EPP [RFC5730]. The only delegation
RRtype it might be possible to use for collision attacks are DS
records. (The other delegation records, NS and glue addresses, are
not signed and their syntax is too constrained.)
Collision attacks using DS records SHOULD be prevented as follows:
o Unknown DS digest types are rejected;
o DS records are required to have the correct length for their
digest type;
o Alternatively, instead of using client-generated DS records, the
registry accepts DNSKEY records and generates the DS records.
6. Other uses of SHA-1 in the DNS
6.1. DS and CDS records
A DS or CDS record securely identifies a DNSKEY record using a
cryptographic digest ([RFC4034] section 5). One of the digest types
is SHA-1. It is deprecated by [RFC8624].
Finch Expires September 10, 2020 [Page 12]
Internet-Draft DNSSEC vs collision attacks March 2020
For this purpose, the digest needs preimage security, which SHA-1
still has, and collision attacks do not affect it.
6.2. NSEC3 records
NSEC3 is an alternative mechanism for authenticated denial of
existence in DNSSEC. It is based on SHA-1 hashes of domain names.
The NSEC3 specification [RFC5155] discusses collisions in some
detail.
NSEC3 can be attacked with an identical-prefix collision, which is
simpler than the chosen-prefix collisions that are the main subject
of this document. The best collision known at the time of writing
[SHAttered] uses two SHA-1 input blocks (128 bytes) so a collision
could in principle be made to fit into a domain name for an attack on
NSEC3. However it will be difficult to make the colliding domain
names conform to host name syntax, and the attack will be futile
because the signer can defeat it by changing its NSEC3 salt
([RFC5155] section C.2.1).
6.3. SSHFP records
An SSHFP record securely identifies an SSH server public key using a
cryptographic digest [RFC4255]. Although SSHFP SHA-1 digests have
not yet been deprecated, SHA-256 is preferred [RFC6594].
For SSHFP records the digest needs preimage security, which SHA-1
still has, and collision attacks do not affect it.
6.4. TSIG authentication
TSIG is a DNS extension for secret-key transaction authentication
[I-D.ietf-dnsop-rfc2845bis]. Its "hmac-sha1" algorithm is
deprecated. Collision attacks do not affect HMAC SHA-1.
7. Security considerations
We find ourselves in an awkward and embarrassing situation. As
Appendix B shows, there has been plenty of warning about the weakness
of SHA-1. Other parts of the industry started making efforts to
deprecate it years ago. But DNSSEC has been complacent.
At the time of writing, there are 1516 top-level domains, of which
1102 use secure DNSSEC algorithms, 274 use algorithms 5 or 7 (RSA
SHA-1), and 140 are insecure. In the reverse DNS, 3 RIRs use secure
DNSSEC algorithms, 2 RIRs use algorithm 5, and many of the non-RIR
legacy delegations are insecure.
Finch Expires September 10, 2020 [Page 13]
Internet-Draft DNSSEC vs collision attacks March 2020
7.1. Staying secure
There are still many domains that depend on SHA-1 to secure
applications that use DNSSEC, such as issuing TLS certificates
[RFC8659] [RFC8555], sending inter-domain email [RFC7672], and
authenticating SSH servers [RFC4255].
Some applications use the "authenticated data" (AD bit) signal from
DNSSEC to make security decisions, and will fail if it unexpectedly
switches off. Other applications use DNSSEC passively and will
silently go insecure. In either case we would prefer them to
continue working as if secure, as long as SHA-1 is still
significantly better than insecure DNS.
7.2. When to declare SHA-1 insecure
At the time of writing, a SHA-1 chosen-prefix collision costs less
than US$100,000 in computer time, takes about a month, and requires
the attention of expert cryptanalysts. Attacks seem to be getting
better by a factor of 3 or 4 per year.
There is not much time before collisions become affordable, and
possible for non-experts to calculate. Section 2 hopes this will not
happen within the next 2 years.
This 2 year guess is likely to be too optimistic, so DNSSEC
validators need to be prepared to disable support for SHA-1 by
configuration change or security patch as soon as a significantly
improved attack on SHA-1 is announced.
7.3. Avoiding unwanted insecurity
The reason for not deprecating SHA-1 immediately is to allow time to
perform algorithm rollovers, so that zones will continue to be
secure.
Abruptly forcing SHA-1 zones to be treated as insecure may encourage
their operators to leave them insecure, instead of encouraging them
to upgrade to a secure algorithm.
8. IANA considerations
This document has no IANA actions.
Finch Expires September 10, 2020 [Page 14]
Internet-Draft DNSSEC vs collision attacks March 2020
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation
Requirements and Usage Guidance for DNSSEC", RFC 8624,
DOI 10.17487/RFC8624, June 2019,
<https://www.rfc-editor.org/info/rfc8624>.
9.2. Informative References
[CABforum2014]
CA/Browser Forum, "Ballot 118 - SHA-1 Sunset", October
2014, <https://cabforum.org/2014/10/16/ballot-118-sha-
1-sunset/>.
[CABforum2016]
CA/Browser Forum, "Ballot 164 - Certificate Serial Number
Entropy", September 2016,
<https://cabforum.org/2016/03/31/ballot-164/>.
[Cochran2007]
Cochran, M., "Notes on the Wang et al. 2^63 SHA-1
Differential Path", 2007,
<https://eprint.iacr.org/2007/474>.
[DNSKEY-IANA]
IANA, "Domain Name System Security (DNSSEC) Algorithm
Numbers", 2017,
<http://www.iana.org/assignments/dns-sec-alg-numbers>.
[I-D.ietf-dnsop-rfc2845bis]
Dupont, F., Morris, S., Vixie, P., Eastlake, D.,
Gudmundsson, O., and B. Wellington, "Secret Key
Transaction Authentication for DNS (TSIG)", draft-ietf-
dnsop-rfc2845bis-07 (work in progress), February 2020.
Finch Expires September 10, 2020 [Page 15]
Internet-Draft DNSSEC vs collision attacks March 2020
[NIST-SP800-131A]
National Institute of Standards and Technology,
"Recommendation for Transitioning the Use of
CryptographicAlgorithms and Key Lengths", January 2011,
<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-131a.pdf>.
[NIST2006]
National Institute of Standards and Technology, "NIST
Comments on Cryptanalytic Attacks on SHA-1", 2006,
<https://csrc.nist.gov/News/2006/NIST-Comments-on-
Cryptanalytic-Attacks-on-SHA-1>.
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
DOI 10.17487/RFC4255, January 2006,
<https://www.rfc-editor.org/info/rfc4255>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC6594] Sury, O., "Use of the SHA-256 Algorithm with RSA, Digital
Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA)
in SSHFP Resource Records", RFC 6594,
DOI 10.17487/RFC6594, April 2012,
<https://www.rfc-editor.org/info/rfc6594>.
[RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC)
DNSKEY Algorithm Implementation Status", RFC 6944,
DOI 10.17487/RFC6944, April 2013,
<https://www.rfc-editor.org/info/rfc6944>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
Finch Expires September 10, 2020 [Page 16]
Internet-Draft DNSSEC vs collision attacks March 2020
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672,
DOI 10.17487/RFC7672, October 2015,
<https://www.rfc-editor.org/info/rfc7672>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews,
"DNS Certification Authority Authorization (CAA) Resource
Record", RFC 8659, DOI 10.17487/RFC8659, November 2019,
<https://www.rfc-editor.org/info/rfc8659>.
[ROGUE-CA]
Sotirov, A., Stevens, M., Appelbaum, J., Lenstra, A.,
Molnar, D., Osvik, D., and B. de Weger, "Creating a rogue
CA certificate", December 2008,
<https://www.win.tue.nl/hashclash/rogue-ca/>.
[ROOT-DNSSEC]
Internet Corporation For Assigned Names and Numbers and
VeriSign, Inc., "Information about DNSSEC for the Root
Zone", 2010, <https://www.root-dnssec.org/>.
[SHA-mbles]
Leurent, G. and T. Peyrin, "SHA-1 is a Shambles: First
Chosen-Prefix Collision on SHA-1 and Application to the
PGP Web of Trust", January 2020,
<https://sha-mbles.github.io/>.
[SHAppening]
Stevens, M., Karpman, P., and T. Peyrin, "Freestart
collision for full SHA-1", October 2015,
<https://sites.google.com/site/itstheshappening/>.
[SHAttered]
Stevens, M., Bursztein, E., Karpman, P., Albertini, A.,
and Y. Markov, "The first collision for full SHA-1",
February 2017, <https://shattered.io/>.
[Wang2005]
Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
Full SHA-1", 2005,
<https://link.springer.com/chapter/10.1007/11535218_2>.
Finch Expires September 10, 2020 [Page 17]
Internet-Draft DNSSEC vs collision attacks March 2020
Appendix A. Acknowledgments
Thanks to Viktor Dukhovni for helpful discussions about the
implications of the SHA-1 chosen-prefix collision.
Appendix B. Timeline
o 2005: Theoretical 2^63 attack on SHA-1 [Wang2005] [Cochran2007]
o 2006: NIST starts to deprecate SHA-1 [NIST2006]
o 2010: DNS root zone signed with RSASHA256 [ROOT-DNSSEC]
o 2011: NIST formally deprecates SHA-1 for digital signatures, and
disallows it after 2013 [NIST-SP800-131A] (section 3)
o 2013: IETF recommends RSASHA1 for use in DNSSEC [RFC6944]
o 2014: CA/Browser forum sunsets SHA-1 in X.509 WebPKI certificates
after 2015 [CABforum2014]
o 2015: Free-start collision demonstrated in SHA-1 [SHAppening]
o 2017: Identical-prefix collision demonstrated in SHA-1 [SHAttered]
o 2019: IETF partially deprecates SHA-1 for use in DNSSEC [RFC8624]
o 2020: Chosen-prefix collision demonstrated in SHA-1 [SHA-mbles]
Author's Address
Tony Finch
University of Cambridge
University Information Services
Roger Needham Building
7 JJ Thomson Avenue
Cambridge CB3 0RB
England
Email: dot@dotat.at
Finch Expires September 10, 2020 [Page 18]
