looking at dnssec deployment in the upper...
TRANSCRIPT
Edward Lewis [email protected] APRICOT 2013 February 26, 2013
Looking at DNSSEC Deployment in the Upper Zones
© Neustar, Inc. 1
Introduction
© Neustar, Inc. 2
» DNSSEC has a number of operational parameters to set » Using the root and TLD zones as examples, started to
measure how they ran DNSSEC » Sizes » Durations
» At APRICOT 2012 this was first presented and then throughout the year more data gathered and stories learned
» At APRICOT 2013 an “annual wrap up” of what was measured, what it means, and recommendations » The work will continue, the talks won’t
What is Measured
© Neustar, Inc. 3
» Key Management » How keys are used, i.e., their cryptographic roles » Algorithms, sizes of keys and other cryptographic elements » Duration, frequency of operator actions
» Other operational choices » NSEC or NSEC3 choice » Delay in DS introduction; “Backup DS records” » Support for old code
» Some of the measurements will be presented here » If interested in other details, contact me later
What Has Been Learned
© Neustar, Inc. 4
» The choices TLDs make » The rationale behind choices (via anecdotes)
» The significance of tool developer choices » Differing views of protocol designers and operators
(comparing RFCs to observations) » Where more study and discussion needed
» What operators want to know vs. what they have time to do » “Gaps” in documents, knowledge » Where tools/code differs from specification
First, Some Adoption Talk
© Neustar, Inc. 5
0
20
40
60
80
100
120
7/1/11 10/1/11 1/1/12 4/1/12 7/1/12 10/1/12 1/1/13
Signed DS
Currently one-third of operational TLDs + root are signed
In Hard Numbers
© Neustar, Inc. 6
» “Up and to the right”, reported quarterly » The study has run for about 19 months
» The number of zones increased from 299 to 306 » This count excludes the 11 test zones in the root » Number of zones signed has risen from 64 to 99 » Number of zones “completed” (DS record) is up from 59 to 89
Adoption by Category
© Neustar, Inc. 7
» 32% of all TLDs (plus root) are signed. How does this compare to members of TLD organizations?
0%
10%
20%
30%
40%
50%
60%
Key Management Study
© Neustar, Inc. 8
» Key Roles » Key Signing Keys and Zone Signing Keys » Presence of Emergency keys
» Cryptographic Choices » Algorithm and Bit Lengths
» Lifecycles » Durations of Key use
KSK, ZSK and Emergency
© Neustar, Inc. 9
» Using “Key Signing Keys and Zone Signing Keys” is an operational choice, not a required part of the protocol » One TLD “joined the club” during the study » All TLDs make the choice to separate keys
» Publishing keys to be used in an emergency can quicken recovery but results in larger response sizes for DNSKEY » Not all TLDs publish emergency keys
Single/Emergency Keys
© Neustar, Inc. 10
Zones by KSKs
Single KSK Double KSK More
Zones by ZSKs
Single ZSK Double ZSK More
» For KSK, 67% choose to have a single KSK key
» For ZSK, the choice is split evenly
Why Not Emergency Keys?
© Neustar, Inc. 11
» Extra keys take up extra space in responses » DNS works better with smaller responses
» Come to think of it, it’s as good a time as any to look at the size of DNSKEY responses…
DNSKEY Response Sizes
© Neustar, Inc. 12
» Looking once shows this distribution of smaller* response sizes (* where a TLD has different sizes)
0
2
4
6
8
10
12
14
16
18
512
540
570
600
630
660
690
720
750
780
810
840
870
900
930
960
990
1020
10
50
1080
11
10
1140
11
70
1200
12
30
1260
12
90
1320
13
50
1380
14
10
1440
14
70
1500
15
30
1560
15
90
1620
16
50
Zones
1280 bytes 512 bytes
Signatures as a Size Factor
© Neustar, Inc. 13
» Number of signatures on a DNSKEY set » This is an artifact of tool choice by the operators
» For the 3-sig zones, sizes were 1217 (x4), 1473, 1621 bytes
Zones
1 Signature
2 Signatures
3 Signatures
Cryptographic Algorithms
© Neustar, Inc. 14
0
10
20
30
40
50
60
RSA/SHA-1 RSA/SHA-256 RSA/SHA-512
Choice of Cryptography
© Neustar, Inc. 15
» Protocol is built to allow multiple algorithms/hashes in a zone
» But all operators uses just one algorithm/hash in a zone » All upper zones use RSA for the algorithm but differ on the
hash function » Over time a shift can be seen » SHA256 and SHA512 were documented (for DNSSEC) in 2009
after many zones started on SHA1 (documented in 2004)
Algorithm Changes
© Neustar, Inc. 16
» Only four zones have changed algorithms, all from RSA-SHA1 to RSA-SHA256
» Of the zones starting DNSSEC during the study » 26 are signed with RSA-256 » 8 are signed with RSA-SHA1
» About one quarter of the “new” (to DNSSEC) operators are starting out with the “old” stuff!
Key Lengths (in bits)
© Neustar, Inc. 17
» The X-axis is “time” Y-axis is number of zones “complying” » Yes, the green line is climbing and the yellow line is falling
in absolute numbers!
0
10
20
30
40
50
60
70
80
90
100
7/1/
11
8/1/
11
9/1/
11
10/1
/11
11/1
/11
12/1
/11
1/1/
12
2/1/
12
3/1/
12
4/1/
12
5/1/
12
6/1/
12
7/1/
12
8/1/
12
9/1/
12
10/1
/12
11/1
/12
12/1
/12
1/1/
13
2/1/
13
2048bit KSK/1024bit ZSK All Others
The Significance
© Neustar, Inc. 18
» In RFC 4641, there is a suggestion to use 2048 bits for KSK and 1024 bits for ZSK. » RFC 4641 is not a requirements document, but customers see
it as one » Over time more DNSSEC zones adhere to these settings » The growth is not only from new deployments but from old
deployments “conforming” to the sizes
» These are the same operators that do not change the hashes!!!
One Operator’s Story
© Neustar, Inc. 19
» When I made this observation, one operator told me a story.
» His deployment had suggested a set of key sizes other than 2048/1024. A reason for this “other size” was a tradeoff in security versus response size.
» The review committee responded by selecting to “go with the ‘normal’ sizes of 2048/1024.
» Peer pressure rules!
Key Lifetimes
© Neustar, Inc. 20
» RFC 4641 suggests that KSKs be used for a year and ZSKs for a month. “Suggests” in the same manner that the RFC suggested sizes. How do operators take this?
ZSK
1 month 2 months 3 months 4-12 months TBD Forever
What about KSK Lifetimes?
© Neustar, Inc. 21
» The study has tracked 193 KSKs » Only 12 KSKs have been through a complete lifecycle in the
19 month study. » Only 7 appear to follow the 1 year recommendation, another
appears to be a 6-month lifetime » The rest seem to be “tests” by the TLD (short duration)
» If operators intended to adhere to a 1 year recommendation, I’d have expected more » But all that can be said is “still not enough data”
Operator Adherence to Spec
© Neustar, Inc. 22
» Just to interject here, operators appear to » Make a decision at design time and stick with it (Algorithm) » Choose size numbers from specifications (Lengths) » Extend the time cycles from recommendations (Durations)
» When it comes to updates » Already operating zones tend to stick with the original » Some of the new deployments opt for the original » Are updates (meaning RFCs) as well-known?
Beyond Key Management
© Neustar, Inc. 23
» Negative Answer Choices (NSEC/NSEC3, etc.)
» DS Record Choices
NSEC vs. NSEC3
© Neustar, Inc. 24
» First there’s the choice between NSEC and NSEC3
» TLDs benefit more from NSEC3 than other zones » Now, let’s look at NSEC3 parameters
Negative Answer Style
NSEC
NSEC3
NSEC3 Iterations
© Neustar, Inc. 25
» Iterations: the number of times the hash function is called » RFC 5155 says this should be low and gives a hard upper
limit of 150 (for a certain key size)
0
5
10
15
20
25
0 1 2 3 5 8 10 12 13 15 17 20 150
Iterations
Low High
NSEC3 Salts
© Neustar, Inc. 26
Salt Changes Never < 1 week month 2 months 3 months longer
Lengths
0 4 6 8 9 10 12 16 20 32
» RFC says “change every resigning” (but no one “re-signs”) » Popular lengths: 0,4,8,16 (hex characters)
» No guidance, but we like “round” numbers! » Interesting values: BA5EBA11, BADFE11A, 5CA1AB1E
=8 hexchars =Never
DS Records
© Neustar, Inc. 27
» How long does a zone wait to add DS records (“complete DNSSEC”)? » 29 were observed, 9 took more than a month. The chart
shows the distribution of those adding within a month
» The “average” delay is getting longer as more zones sign » And zones signing without adding DS is growing too
0
1
2
3
4
0 5 10 15 20 25 30
Zones
Question: Emergency DS?
© Neustar, Inc. 28
» During discussions over the study one person asked whether any TLD pre-registered a DS record in case of an emergency. » I.e., has there been a DS record in the root that did not point to
a DNSKEY in a TLD?
» The answer is: only one TLD has put a DS record into the root zone this way » It took a lot of time to find it!
Support for DS hashes
© Neustar, Inc. 29
» RFC 4509 defines a new hash for DS records and recommends that old hashes be kept for backwards compatibility
» “New Only” and “Old Only” force clients to support old and new, this is not good for transition!
Zones with DS
New Only
Both
Old Only
The Last Slide
© Neustar, Inc. 30
» What has been learned? » Study how something is deployed…is interesting » Operators rely more on tools than on specifications » There are still gaps in knowledge about DNSSEC and the
cryptography it uses
» It would be nice if there were documents describing “Best” or “Good” Current Practices as “buying guides” as a replacement for not having true specifications