Edward Lewis ed.lewis@neustar.biz 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