At 3:27 PM -0500 1/21/10, Andrew Sullivan wrote: >On Thu, Jan 21, 2010 at 12:12:50PM -0800, Eric Rescorla wrote: >> On Thu, Jan 21, 2010 at 11:38 AM, Paul Hoffman <[email protected]> wrote: > >> > is still much higher than the value of the broken key. Remember >> > that a broken signing key is only valuable until the fact that it >> > is broken is discovered and fixed. So, even if an attacker breaks >> > your signing key, when he/she starts to use it for nefarious >> > purposes and you discover that, you roll your key and the entire >> > time of breaking the new key must be used again before they can >> > mount another attack. >> >> Exactly. So rolling it preemptively doesn't help much. > >What about the argument that you might not discover the nefarious use >(because a small number of DNS transactions, carefully selected, are >the only misdirected ones, and everything else appears normal, so you >chalk it up to user error)? Remember that unlike many cryptographic >protocols, there's no real end-to-end communication here. It could >well be hard for a key owner to detect the compromise in a DNS context >than in many other contexts. > >If one accepts that argument (I don't know I do, but let's accept it >for the sake of argument), then rolling regularly (modulo jitter) >could be argued for on the grounds that it will cut off even >undetected compromises.
...as long as there is no cost to rolling regularly. But there are many: - A botched roll can cause validating resolvers to not trust any of your answers - A botched roll can (I think) cause your zone to go bogus - Regular rolling can give you a false sense of security about your rolling process These are about as intangible as the cost of an attacker using a compromised key until you discover and change the key. Thus, you want to make the cost to the attacker as high as possible. The easiest way to do that is a longer key, such as 2048 bits, or a better signing algorithm, such as ECDSA. --Paul Hoffman, Director --VPN Consortium _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
