On 2 Apr 2014, at 10:26, Ted Lemon <ted.le...@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
