On Tue, Oct 18, 2011 at 12:45 PM, Kevin Gross <[email protected]> wrote: > Nico's contention is that it should take a constant amount of time to > decrypt a packet once it is received. I don't think this is exactly true but > when compared to other (variable) latencies in the system, possibly a > reasonable approximation.
Not constant so much as deterministic (for some algorithms, and some implementations, but I assume that side-channels are not desirable, which leads to the assumption of deterministic timing) or measurable. In practice measuring this time is probably difficult, for example, in preemptible kernel designs, or if the HW lacks a sufficiently high resolution timer or CPU cycle counter. I grant then that the proposed solution is simpler to implement. But should the proposal be negotiable, and if so, how? > If an attacker delays or drops synchronization packets, clock quality will > suffer. In the extreme case, all useful clock communication is lost and > nothing works. I don't think this situation is any different for clock > traffic than it is for other traffic. Encryption cannot prevent denial of > service. However, encryption can make it harder for an attacker to delay just the timing packets (though not impossible given enough meta-data leaking to mount effective traffic analysis). Or, to put it differently, making timing packets identifiable makes it easier for an attacker to DoS only the timing exchanges but not the rest. DoS attacks based on not allowing packets through, or delaying them, generally cannot be avoided, so perhaps there's no cause for concern. I think you'd want to have a security consideration describing the problems that might arise from a selective DoS attack on timing, as well as mitigations. Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
