In message <[email protected]>, Masataka Ohta writes: > Hosnieh Rafiee wrote: > > > I guess this problem is also true for any protocol that uses timestamp in > > their signature and not DNSSEC specific. > > Not necessarily. Some security protocol can safely assume > clocks of related equipments are manually managed by skilled > operators, which is not the case with DNS clients.
Most people are capable of setting the clocks on their laptops, phones and other portable equiment which all should be validating responses. Most people are capable of setting clocks on their desktop machines which should be validating responses. If the router takes a leap of faith w.r.t. time then it just shouldn't set AD on its responses though should still validate responses. This is significantly better than not validating responses and unless all the DNS responses are being compromised will result in lots of DNSSEC validation failures on responses. Downstream validators will not be able to get valid answers for the forged data (as the forged data will be cached) but will get valid answers for the unforged data (as this will not be cached but will be returned with cd=1) with a compromised time. This makes the attack visible. > Then, plain DNS modified to have 32 (or 64?) bit messages > ID is as secure as DNSSEC. No it is not as there is well known examples of ISP's and hotspots poisoning DNS responses. This is not to say we shouldn't be using larger id's as they will make it less important to randomise ports. > > Because the nodes need to consider > > clock skew (for at least a few seconds) and this is actually where the > > attacker can attack the node (replay attack.... ) > > If the skew were few seconds, it is not a security problem > for DNS. Nor even hours if signers set the inception time to more than a hour in the past. > The problem is that, without human intervention by skilled > operators, clocks can be very inaccurate. And the effects of bad clocks will be seen once stub resolvers routinely validate responses. > Then, a compromised and expired zone key can be used for > arbitrary data of the zone, which is more serious than > replay attack. > > > Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
