Subject: [DNSOP] One more bit of Whiskey Tango Foxtrot on key lengths...

From: Nicholas Weaver <[email-masked]>
Date: Thu, 27 Mar 2014 13:15:00 -0700

The overall problem of using old root keys will persist (and eventually I think DNSSEC resolvers need to refuse ZSKs for . and tlds that are less than 2048b in length, or barring that, need to add a clock ratchet to keep old keys from being reused).

But fixing this going forward requires a 1-line change in the ZSK script:

-b 2048

That's it.  Since the KSKs are already 2048b, and therefore there are appropriate RRSIGs, its clear that the server side is set up to handle real key lengths.

--
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: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 28 Mar 2014 09:34:51 +0100

On Thu, Mar 27, 2014 at 01:15:00PM -0700,
 Nicholas Weaver <[email-masked]> wrote 

> But fixing this going forward requires a 1-line change in the ZSK

I have nothing against longer keys but this sort of sentences ("DNSSEC
is simple, anyone can do it in five minutes") is a sure way to inflame
me. It is not sufficient to change the script, you also have to search
if it can break things later. A typical example would be the larger
response to the DNSKEY query. If changing the key size make it larger
than the MTU, it _may_ create problems.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 28 Mar 2014 05:24:27 -0700

> than the MTU, it _may_ create problems.

It doesn't.  If you have 2 DNSKEYs and one RRSIG, a 2048b KSK and a 1024b ZSK, it goes from 750B to 880B.  With two ZSKs it goes to 1100B.  You only have an issue if you have 3+ ZSKs valid.

Or then you have cases like .org, where you are using 1024b ZSK keys but because there are enough and a key roll of the KSK and other crud going on right now, its ALREADY busting the MTU limit as you have 2 1024b keys, 2 2048b keys, and 2 2048b RRSIGs.  So if MTU was an issue, that would already be up and biting people...

> dig +dnssec DNSKEY org @199.19.56.1
...
;; Query time: 123 msec
;; SERVER: 199.19.56.1#53(199.19.56.1)
;; WHEN: Fri Mar 28 05:16:16 2014
;; MSG SIZE  rcvd: 1625

Yes, its deliberately inflamitive on my part to say its "just a 1 line change", but sweet jeebus people: IF DNSSEC wants to actually be taken, you know, seriously as crypto, using 1024b signatures in the key positions of root and the TLDs is not gonna cut it.  It is safe to assume that 1024b RSA is broken by nation state adversaries.  NIST recommend it it be deprecated in 2010, and all use stopped in 2013.

And the code paths are well tested: resolvers hit fragments more than enough on DNSSEC for any resolver which validates and has fragment issues to have sucky performance as it dropped its MTU to 512b [1], while since the KSKs are 2048b the crypto is already flowing, the code paths are well tested.

[1] Yes, I've many times pointed out that the first stage EDNS0 fallback should be to 1400b, but I doubt that code has changed at all yet...