On Wed, 2 Apr 2014, Nicholas Weaver wrote:
Well, its because for the most part, cryptographers do seem to understand that
DNSSEC is a bit of a joke when it comes to actually securing conventional DNS
records.
Funny, the cryptographers I talk to, like at the University of Waterloo,
have always told me our key sizes are giant for the deployment time we
are using them and that we're far above minimum.
And the NIST crypto recommendations have existed for years. 1024b RSA was
"deprecated in 2010, eliminate completely in 2013". There may be doubt in NIST
now, but 2 years ago, to ignore the standard recommendations is foolish.
I love how people now cherry pick NIST. If it agrees with them they
quote it. If it disagreed with them they shout NSA subverted them.
Do your resolvers have protection against "roll back the clock" attacks? If not, you do
not "gain protection" from the short-lived (well, really, a few month, they don't roll
the actual key every 2 weeks) nature of the ZSK for root, .com, etc.
Yes, there is a 5011 unbound anchor verification on some of them. And
ntpd doesn't let you jump months in a second either, so only systems
that run ntpdate before ntpd are vulnerable, and only those systems
without a battery backed up clock should do that.
Saving space and time does matter. Roughly half the operators I studied would
include a backup key on-line because “they could” with the shorted length. And
performance does matter - ask the web browser people.
Because we want to make security decisions based on a 1ms latency browser war?
Amdahl's law seems to be something that computer science in general always
seems to forget. The performance impact, both in size and cryptographic
overhead, to shift to 2048b keys is negligible in almost all cases.
Mind you, I agree we can move to 2048 for ZKSs
And the step function in DNS cost, the "Internet can't do fragments" problem,
doesn't really come into play at 2048b.
I don't think the entire cannot do fragments issue is really still a big
problem. Networks using/depending on 8.8.8.8 has actually cleaned up a
lot of the transport issues involved I think.
It nets to this - cryptographers urge for longer lengths but can’t come up with
a specific, clearly rational, recommendation.
Yes they have. 2048b.
Actually my Waterloo cryptographer said you can pick something smaller
than 2048 and larger than 1024 too.
DNSSEC is actually useless for, well, DNS. A records and the like do not
benefit from cryptographic protection against a MitM adversary, as that
adversary can just as easily attack the final protocol.
You are mixing in local vs global attacks. For example, Brasil's attack
where the majority of cable modems got their DNS setting changed for
their DHCP server. If hosts were running DNSSEC with using their ISP
as forwarders, this massive attack affecting millions would have
failed. So your statement is rather simplistic and wrong.
Building the root of this foundation on the sand of short keys, keys that we
know that are well within range for nation-state adversaries, from the root and
TLDs is a recipe to ensure that DNSSEC is, rightly, treated by the rest of the
world as a pointless joke.
Actually, I would LOVE to see a rogue entry signed by the root ZSK. It's
a giant enigma problem if the USG can make these. Please do invite me to
the root-servers meeting following that exposure.
I don't think there is a reason not to switch to 2048 for ZSKs. But I'm
basing that on "there are no significant transport obstacles left".
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
