On Mar 28, 2014, at 1:34 AM, Stephane Bortzmeyer <bortzme...@nic.fr> wrote:
> On Thu, Mar 27, 2014 at 01:15:00PM -0700,
> Nicholas Weaver <nwea...@icsi.berkeley.edu> wrote
> a message of 75 lines which said:
>
>> But fixing this going forward requires a 1-line change in the ZSK
>> script:
>
> 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.
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...
--
Nicholas Weaver it is a tale, told by an idiot,
nwea...@icsi.berkeley.edu full of sound and fury,
510-666-2903 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
