Re: [DNSOP] key lengths for DNSSEC

Speaking for myself:

First:  Thank you Jim and Joe for seeking to increase the signal-to-noise ratio on this thread and for explaining what the attack vector would be for lower IQ folk like myself.

Second: I have always taken my instructions from the community. So regardless of what I believe I will faithfully do my part (with your help) to make it happen.

Third: From my vantage point and as author of the code used for the KSK side of things, I do not see any immediate barriers  to increasing key lengths.  The members of the original root DNSSEC design team have enjoyed a very good working relationship and I expect that to continue.  However, like any other change at this level it must be one that is approached conservatively and thoroughly tested before deployed (software, increased RRSet sizes, IPv6 impact, new ZSK generation).  This will take human resources and time.

I look forward to following further discussions on this topic.

-Rick

-----Original Message-----
From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Joe Abley
Sent: Wednesday, April 02, 2014 7:50 AM
To: Ted Lemon
Cc: IETF DNSOP WG
Subject: Re: [DNSOP] key lengths for DNSSEC

On 2 Apr 2014, at 10:26, Ted Lemon <Ted.Lemon@nominum.com> wrote:

> The problem with the way you've phrased this question is that there does not seem to be agreement amongst the parties to this discussion whether old keys matter.   If you think they do, you need longer keys.   If you think they don't, you need shorter keys.   So rather than talking about key lengths first, it would be more productive to come to a consensus about which threat model we are trying to address.

I'm trying to understand the time-based attack, but I'm not seeing it.

The gist seems to be that if I can turn back the clock on a remote resolver, I can pollute its cache with old signatures (made with an old, presumably compromised key) and the results will appear to clients of the resolver to validate.

This sounds plausible, but without administrative compromise of the remote resolver (in which case you have much simpler options) this attack seems to involve:

1. subverting sufficient NTP responses over a long enough period to cause the remote resolver's clock to turn back in time (long period suggested due to many/most? implementations' refuse large steps in times, and hence many smaller steps might be required)

2. replacing every secure response that would normally arrive at the resolver with a new one that will validate properly at whatever the resolver's idea of the time and date is (or, if not every, sufficient that the client population don't see validation failures for non-target queries). This potentially involves having factored or otherwise recovered every ZSK and KSK that might be used to generate a signature in a response to the resolver, for the time period between now and then.

This seems like an intractably difficult thing to accomplish.

What am I missing?

Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop