On 26 mrt 2008, at 14:36, Eric Rescorla wrote: > - Modern cryptographic implementations are extremely fast. For > comparison the MacBook Air I'm typing this on will do order 10^6 > HMAC-MD5s/second on 64-byte packets. So, to consume all my > resources would require order 10^8 bits per second, which is a > pretty serious packet-based DoS ittack on many contexts. This is a bogus argument. Implementations are always inferior to optimistic performance claims and although maybe your laptop CAN do that that doesn't mean you WANT it to spend its cycles and battery power on that. (Or maybe you do, but I certainly don't.) > - Even mounting this attack requires knowing both host/port > quartets. With DTLS, as with TLS, the responder/server's > port is typically known whereas the initiator/client's port > is random or pseudorandom. This creates some barrier to > mounting this attack. The DTLS design to reuse the port numbers is not unreasonable as long as DoS against CPU resources isn't a concern. But not using random sequence numbers, like TCP has been doing since the dawn of time, is a serious oversight because it costs next to nothing and buys a lot of protection against spoofing attacks. > - A very similar attack is available on IKE (and DTLS, of > course). In order to block DoS attacks, both handshakes > offer the option of doing a "stateless cookie" exchange, > in which the responder gives the initiator a token which > can be used to verify the client's next message (which must > of course contain the token). But the way these tokens are > generates is to have the responder compute a cryptographic > MAC/hash over some input data. So an attacker can force > any random IKE or DTLS stack to do as many digest operations > as it wants. That doesn't make sense. For such a cookie to provide additional benefit over the normal HMAC, the value in the next message must be present in that next message in the clear so the number of crypto operations required is equal to the number of valid packets, which isn't under the control of an attacker, rather than the total number of packets (like a HMAC), which can be inflated by an attacker. >> The part that I don't like about DTLS is the way it avoids dealing >> with MTU issues and pretty much tells people to do PMTUD for IPv4 for >> UDP even though in theory this is extremely hard to get to work and >> practice it never works. > You've misunderstood the purpose of DTLS, which is to replicate > the semantics of UDP to the greatest extent possible, consistent > with also provided an association-based security system. Accordingly, > since UDP-based applications have to deal with PMTU, they have to > do so with DTLS as well. I wasn't offering a critique of DTLS' purpose, but rather, of its operation. Path MTU discovery for IPv4 for UDP can only work if applications can adjust their packet sizes arbitrarily, which they often can't, or at least not in a reasonable way. Perpetuating this broken idea in DTLS was a mistake. _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf