[Top] [All Lists]

Re: TLS vs. IPsec (Was: Re: experiments in the ietf week)

2008-03-26 06:37:01
At Wed, 26 Mar 2008 13:25:20 +0100,
Iljitsch van Beijnum wrote:

On 25 mrt 2008, at 16:10, Dan Wing wrote:

And yes, the issues I referred to are DoS and TCP spoofing.
These can only be protected against at the  network level.

What are your thoughts on DTLS's DoS and spoofing protection?

Looks like this is mostly similar to IPsec except that the port  
numbers rather than SA is used to demultiplex so the anti-DoS  
protection that the sequence number / anti replay counter provides is  
less than with IPsec.

You really need to describe the attacks you're concerned about, rather
than handwaving. After reading this a few times, I *think* you're
claiming the following:

    An attacker who knows the host-port quartet of a DTLS association
    can send send completely bogus but correctly formatted packets to
    one side and therefore force them to attempt to decrypt the
    record. This amounts to a computational DoS attack. Whereas, by
    contrast, mounting this attack on IPsec requires knowing the SPI,
    which presumably requires being on path, since it's random.

Do I have this right?

If so this is a pretty feeble attack. 

- 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.
- 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.
- 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.

I assume this means in the future we'll be running TCP over DTLS over  

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.


IETF mailing list