Subject: [DNSOP] DNSKEY RRset size and the root

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Jan 2015 14:56:36 -0500 (EST)

Let me clarify things a bit,

The root ZSK key is 1024 because of assumed packet size issues.

nohats.ca is currently publishing 3 2048 bit keys, and has a message
size as reported by dig of 1163. That's even under 1500 (and came in on
UDP). So what's the problem of moving the root ZSK to 2048?

The current root DNSKEY RRset 736 bytes. More when there is a key rollover.

Provided packet size is an issue, how many TLDs would these problematic
clients not be able to resolve? Let's see (scriptkidiedescript):

DNSKEY RRset sizes vary between 569 and 2969 bytes.

Top twenty sizes:

count  TLD
42 983
37 980
31 986
28 989
27 977
26 747
25 893
20 745
18 1340
17 995
17 1621
16 897
16 1175
16 1171
15 907
15 749
14 895
14 1337
14 1169
13 992
12 974
12 1629
12 1334

59 TLDs out of 840 TLDs (or 7%) with DNSKEYs are larger than 1500:

       2 2969
       2 1898
       1 1788
       1 1693
       2 1669
       6 1657
       2 1641
      12 1629
       8 1625
      17 1621
       2 1567
       4 1537

Probably if you track these for a few months to capture all TLD rollovers,
the number of TLDs that are ever in a size > 1500 is much higher.

Then of course, how many second and third level domains just run with
only 2048 bit KSK/ZSKs? All of those would currently cause problems
despite the root 1024 ZSK "accomodating" them on the first step of the
validation process.

In other words, which ever clients cannot handle a root ZSK of 2048
already has a severe problem with DNS. I don't think we would be adding
much of a problem by just switching to 2048 today.

Of course, once you believe we can do a ZSK of 2048, there is no urgency
to move to ECDSA and we can wait on the CRFG to come up with a non-DSA
ECC algorithm for us.

As an aside, you can sign your zone's DNSKEY RRset with only the KSK,
but some zones still sign it with both ZSK and KSK. The root signs with
just the KSK.

And as an example, this is the root DNSKEY RRset:

; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-16.P2.fc19 <<>> +dnssec
dnskey .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6705
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;.				IN	DNSKEY

;; ANSWER SECTION:
.			137698	IN	DNSKEY	256 3 8
AwEAAe3fSrbLBy3LOS7pnxEUhvPZTE2H5dIGsI/UfruI/nOEvWWa/PSX
2BFedBkEqOlYdjdNF2f+6lmfk2Od/xu0v5bVqxFE+/24v3hZSlWBxvXz
PTAGHrbW/IJYEPqlzVOAS4XdUgHg0N7IbLywNHMvB+Yf+Nm6ctyXXFLV 4WTNnzs7
.			137698	IN	DNSKEY	257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=
.			137698	IN	RRSIG	DNSKEY 8 0 172800
20150125235959 20150111000000 19036 .
XadYgN9kxC9kchTC9Vqsl+WOgyWghjw1CWpiG42xjdpxd9EkHQLkJd3g
rhzZNJ1VYJk1B2Czx1Lh2tM0ctUXDXKs3+IGqcbY141TTj6q6lQdtkuw
kTLkuGIyZYd2rEt0oX0MV6HSUXejmPbe66EpkwrfQ+wBGpPkrGk1IbCr
qZ8g8CpvTkCx68Z0NC1oD93Pfc8zTH5jyA0r4Lj/p/S2NrP4BtEAatvM
WtboFfgY2duy7glWDbvO55QTaTygdrBQgf4l4+SU8LBRdEA5jSSQLSed
rB2lL933VRUujmFtSO6XK39SK0s2CSbcxeBBhtLefHOn7HPAY2g37pNj KN47LQ==

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 19 14:54:27 EST 2015
;; MSG SIZE  rcvd: 736

And this is .au:

; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-16.P2.fc19 <<>> +dnssec
dnskey au +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2995
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;au.			IN DNSKEY

;; ANSWER SECTION:
au.			84726 IN DNSKEY	256 3 8 (
 				AwEAAbYbMN6XklMRQZV45zPkpfgKuE99d7ffemBlJfIV
 				99qq1x6QK22V+nRjPsp1LyrgMqrHMdBimsbbjYPN8NA8
 				25kgFMKpJXG2fJMCmsn2OwGhZ8UembIHhpCIfnBRdoBA
 				VQdgCYV+hrfLB3MWsUQUlQWSLITsbfU+4IZJJ9RfVxLY
 				iVZ3GfBv+3QVi4uvy0uFElCl4nuOsKg1t2UMn3peE1s=
 				) ; ZSK; alg = RSASHA256; key id = 48759
au.			84726 IN DNSKEY	257 3 8 (
 				AwEAAcFzdKOB1r9JFKuXUMg9E0VKmr3gJU+nJYn0w3gF
 				NYrDY/oXPQpxAFznHgKtamqXJ4jO6hacAFguStvXoKQe
 				De74vdRatwMR1b0I2gMHmIlyd0cfvE7oLxLBop9rKzSi
 				00RFFa6MXmaHuHsNWUOGwlzIsI3sWTpeSTUQ1Nzn+96M
 				zBY6yNDm4abtSlt9ptPU5JSomAB7bgHt69SxEUOHfrZo
 				T5u8X1fCIyZ/cS6SmR+sbU00qJ2PD+cmGWELpQgrXUOw
 				xm3+6qO5+0MEHMvKTAkWVGlj4wj2W/TxYw2ZpAoJbdA3
 				XKry7S0c2Mha22CgQBku7EpxBi4WjojRGzuBIoU=
 				) ; KSK; alg = RSASHA256; key id = 5381
au.			84726 IN DNSKEY	257 3 8 (
 				AwEAAbOSMtg7G2ixOlGPuhFhNiI7HUT2lNmgYPsuIzUr
 				5Rj0SPGv0aJNCWkFkYH87TxYs92JpU+VbLsokXGo9k2Q
 				vvZktFKZu61sENfOhK6w7DkqiSt2Do0rb5gpZHugr9Ay
 				S8iwegMumTuD76PjA2d34VrTt02+mqpDq1zGLpeY2kMC
 				BRQdhxHqX+BhJbCB7ogaz9yj8YEaIZ49dHfHDc9ZrjEc
 				z71S1YDLpi98yx2RbiaqBRSiH8JrVQrG7lSu2K4PS/A5
 				tQH2SgljpytW0mIKTtT8vrNVaw8L6uTILjyZqZNhu8Tw
 				IWRs9Hmz1BFdury6sDEPy2Zq9q0azL7HJBKY4As=
 				) ; KSK; alg = RSASHA256; key id = 37976
au.			84726 IN RRSIG DNSKEY 8 1 86400 (
 				20150419093525 20150119085951 5381 au.
 				E7wBPWwis6t2s4A3X0sIn7CHfgIc+b0HKU5y7ONsncQ+
 				efn9zdKIgy654ax3Xo9CMk8Qrw2PMicWPXtiDfE4/GVX
 				LxPZAxrm4LdZgT8xMhVU192Rv+9TGu0/1CbjjzJrSE2g
 				06h9p8/8PKsOiGKr6rD1oQ9YJg5Js8qRkGTXcNkGOVS1
 				ThH/xq5mLbpjUijCySiJmrTvazYjMSEl8QZk/iQXWmE2
 				jM8c38PZmLt45xDVGUDAbct/vKMaWrhs+vraRYaH9IEa
 				OO6+IkAN2uOtNmTUXNe/lssMSPtwPf2PVxQwtvbUgzdN
 				db33ESs/whLD/ozuRQPzGcnjHT/vIl9olw== )
au.			84726 IN RRSIG DNSKEY 8 1 86400 (
 				20150419093525 20150119085951 37976 au.
 				mjyDoBO/WtZZJV4vbnoCoSsJQxIMypiaSl5cjGtzo2A+
 				iIXj7INNMrCMtjP5zJKsmDskSgHjWtOOb4xwZvOaFjDh
 				xkWy/t8ynlvPyEIsPwkKrZ4UbF8vjuEsmGmIeoC8TXts
 				Dc1nVOTD+oCZGcrJ2HRReStPsqb0aYiO/j2MaaSa4eNh
 				7ZOCLnyywl6LKcxyR2/afgP0Kvy6qArqGYtZnums8QMb
 				ECHcP+1J9jhLZ4fQ/PO14xGjebc0BAfOKkq8X4hPqKX4
 				Qth1k5Xd3yYL30xp4s55uUDzm0iCjRMx2mK2d+092SSj
 				xRvUmqpLE15S4UgYa+EFmkJlC+auvLQJ6A== )
au.			84726 IN RRSIG DNSKEY 8 1 86400 (
 				20150419093525 20150119085951 48759 au.
 				ecRq6vUWcEdxUi90nLc2WaUAmJ2fSmX/AF9jsDNB7rhT
 				o4Ap7S4ITL5L1YA/V001f5d0hc1c6CkUVz3h2VDVi4gi
 				SHlVJKoa2vWXicNWe6ym0c5srqCUZ9Q1pi4B1WBHKX5B
 				UZjQiIueBoV4t9iXIsFxZPaCeYoYk1rUU4J6NaZ2Zps2
 				XaqOu8tflecLFtEOK3hAU6Gnhg2RkerWwUJcxQ==
)

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 19 14:53:08 EST 2015
;; MSG SIZE  rcvd: 1537

So unless Australia is not reachable by a significant portion of the
world doing DNSSEC, the root is not going to see an issue either.

Paul

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Jan 2015 16:54:02 -1000

Paul,

> Let me clarify things a bit,

Thanks very much for this note. The issue of the ZSK length is something that has popped up on various radars on various occasions and given the recent publicity over at imperialviolet and sockpuppet on 1024 bit RSA, it'd be good to explore this in more detail to see what level of nightmare we'd be inflicting upon ourselves (if any).

> much of a problem by just switching to 2048 today.

While I tend to agree, this assumes the clients would notice, which obviously depends on the names being looked up. Do you have any idea of (say) the popularity of the names behind large RRsets (e.g., their Alexa ranking or something similar)?

> to move to ECDSA and we can wait on the CRFG to come up with a non-DSA

Yep. I'd really like to go to ECDSA, but it doesn't look like there is enough support out there for it (at least for root purposes).

> world doing DNSSEC, the root is not going to see an issue either.

According to http://w3techs.com/technologies/overview/top_level_domain/all (random stats site select by closed eye googling, no idea whether their methodology is reasonable), .AU represents 1% of websites.  If 20% of DNS queries are doing DNSSEC lookups, and a small fraction of those are behind broken middleboxes that puke on large RRsets, I can (barely) see an argument that the universe is too small to make a reasonable determination...

I guess a larger question is "do we care?".  I'll be honest and say I'm increasingly concerned that broken middleware-driven ossification is getting in the way of fixing serious problems.

Regards,
-drc

---

From: Paul Wouters <[email-masked]>
Date: Thu, 22 Jan 2015 13:12:51 -0500 (EST)

> Thanks very much for this note. The issue of the ZSK length is something that has popped up on various radars on various occasions and given the recent publicity over at imperialviolet and sockpupp…

I think it was a bigger problem when the root was signed at first.

> While I tend to agree, this assumes the clients would notice, which obviously depends on the names being looked up. Do you have any idea of (say) the popularity of the names behind large RRsets (e.…

No, I don't. Someone at a big caching server would be in a much better
position to get that data.

> Yep. I'd really like to go to ECDSA, but it doesn't look like there is enough support out there for it (at least for root purposes).

Some people would like to skip ECDSA for a more modern ECC variant.

> I guess a larger question is "do we care?".  I'll be honest and say I'm increasingly concerned that broken middleware-driven ossification is getting in the way of fixing serious problems.

And those middle boxes already have a fallback - don't query with DO.

Paul

---

From: Liang Zhu <[email-masked]>
Date: Fri, 23 Jan 2015 09:40:56 -0800

> And those middle boxes already have a fallback - don't query with DO.

There have been repeated questions about how big DNSSEC keys should
be. We are also interested in understanding at what point IPv4
fragmentation becomes common in UDP responses as key size increases,
since IPv4 fragmentation brings performance problems such as packet
re-transmission due to loss fragments.

We analyze two DNS traces captured at a root server and a TLD server,
by replacing the current 1024-bit RSA signature with longer ones. We
find that:

1. A root trace suggests there is minimum (almost no) risk to go to
2048-bit ZSK and 2048-bit KSK for root server.

2. A TLD trace shows 5.5% DNSSEC enabled responses getting IPv4
fragmented with 2048-bit ZSK and more with longer keys. We suggest TLD
and other authoritative server operators analyze their server's
response traffic and inform their customers of possible problems
before moving to use longer keys.

For details of our methodology and graphs, please see
http://isi.edu/ant/tdns/keysize.html

-Liang Zhu

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 23 Jan 2015 10:01:49 -0800

> http://isi.edu/ant/tdns/keysize.html

What is the problem with #2? IP fragmentation happens, and The Internet is expected to work with it. That is, of what possible value is "inform their customers"?

--Paul Hoffman

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 23 Jan 2015 10:12:48 -0800

> On Jan 23, 2015, at 10:01 AM, Paul Hoffman <[email-masked]> wrote:
> 

The Internet has unfortunately decreed that Fragmentation Does Not Work with IPv4, and Really Does Not Work with IPv6.

This will cause timeouts until the resolver realizes it should use a smaller EDNS0 MTU and in that case, the resolver will failover to TCP for that query, which some in the DNS community view as anathema...

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Mark Andrews <[email-masked]>
Date: Sat, 24 Jan 2015 07:50:48 +1100

In message <[email-masked]>, Nicholas Weaver writes:
> > What is the problem with #2? IP fragmentation happens, and The Internet
> is expected to work with it. That is, of what possible value is "inform
> their customers"?
>
> The Internet has unfortunately decreed that Fragmentation Does Not Work
> with IPv4, and Really Does Not Work with IPv6.

No.  Firewall vendors are too lazy to properly design them to handle
fragments.  There is nothing inherently wrong with using fragments.

You don't need to reasemble packets to filter them.  Adding two on
demand entries would let the reply traffic get through without it
being wide open to all fragments.

source addr + dest addr + protocol + fragoffset == 0 + src port + dest port
source addr + dest addr + protocol + fragoffset != 0 

Firewalls today add the first of these rules but not the second.
You could turn the != into a > x where x covers the layer 3 protocol
header.

"pass udp any any frag" works when the firewall vendor doesn't add
the second on demand rule.

> This will cause timeouts until the resolver realizes it should use a
> smaller EDNS0 MTU and in that case, the resolver will failover to TCP for
> that query, which some in the DNS community view as anathema...
>
>
> --

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Fri, 23 Jan 2015 13:47:59 -0800

> Mark Andrews <mailto:[email-masked]>
> Friday, January 23, 2015 12:50 PM
>> ...

if you said "theoretically" rather than "inherently" i would agree.
because from a practical standpoint, nicholas is correct, and RFC 2671
was wrong-headed. the authors of "Fragmentation Considered Harmful,
WRL-87-3" (online at
http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.html) were my
direct supervisors in 1988 and 1989, and i had read this paper and
agreed with it. yet, a few short years later my body was apparently
taken over by a space alien who had not read this paper, yielding RFC
2671 and all of its fragmentary evils.
> ...

yes, and, i have this rule in all my firewall rulesets where "pass udp
any any 53" is also present. let's assume that all readers of this
mailing list also do, because, that's the reasonable thing for educated
people to do. there would still be no place in today's world for any
wide area protocol that depends on working end-to-end fragmentation,
because too many DNS protocol endpoints are behind middleboxes that are
either not configurable, or which can only permit fragments if you turn
on statefulness (which yields a far worse result), or because the
operators are unaware (and will never become aware) of this problem.

this is why RFC 6013, and
<http://static.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf>,
exist. sadly, the tcp-m WG did not agree with that approach. the goal of
"robust cookies" was to retain compressed connection state on the same
order of cost magnitude as is universally used by compressed TCP SYN
flood protection state, so that sessions would become "mostly dead"
rather than "fully dead" after the FIN/FINACK. this allowed
multi-segment responses to single-segment requests, which is the same
packet flow as for EDNS, but with zero danger of DDoS reflection or
amplification. (google's tcp-fastopen has similar aspirations but with
nothing like the same security profile.)

-- 
Paul Vixie

---

From: Paul Wouters <[email-masked]>
Date: Fri, 23 Jan 2015 17:01:06 -0500 (EST)

>>> with IPv4, and Really Does Not Work with IPv6.

It seems this issue is being escalated as we speak!

"Internet fragmentation worries world business leaders"

http://www.cbc.ca/m/news/technology/internet-fragmentation-worries-world-business-leaders-1.2929863

*ducks*

---

From: Liang Zhu <[email-masked]>
Date: Mon, 26 Jan 2015 09:58:00 -0800

> This will cause timeouts until the resolver realizes it should use a smaller EDNS0 MTU and in that case, the resolver will failover to TCP for that query, which some in the DNS community view as an…

Besides the additional latency caused by loss recovery, as Nicholas
said, fragments may also bring problem of fragmentation attack
described in:
A. Herzberg and H. Shulmanz. Fragmentation considered poisonous. In
Proc. of IEEE Conference on Communications and NetworkSecurity (CNS),
Oct. 2013.

-Liang Zhu

---

From: Mark Andrews <[email-masked]>
Date: Tue, 27 Jan 2015 10:30:22 +1100

In message <CAC3z6OhoYkmSiJLqHA55W_3i8GN94QR9fQbndDOj=[email-masked]>, Liang Zhu writes:
> > This will cause timeouts until the resolver realizes it should use a smaller EDNS0 MTU and in that case, the resolver will failover to TCP for that query, w
> hich some in the DNS community view as anathema...
> >
> 

And they are completely defeatable at the application layer.
 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop