[Top] [All Lists]

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

2008-03-26 07:35:12
At Wed, 26 Mar 2008 15:01:21 +0100,
Iljitsch van Beijnum wrote:

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 

What do you mean "optimistic performance claims"? I ran
"openssl speed". That's actually a pretty good reflection
of what the performance of SSL implementation will be.

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

No, I don't, but once again you're totally missing the point:
the amount of bandwidth you'd need to perform a computational
DoS attack on the symmetric part of the system is so high
that it's basically a bandwidth-based DoS in itself.

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

1. TCP has *not* used random sequence numbers since the dawn of
   time. On the contrary, they have been historically extremely
   predictable, hence RFC 1948 (though of course the techniques
   predate it.) And the reason that it now uses random sequence
   numbers is to block attacks much more severe than the ones
   you're describing here.
2. You're using the term "spoofing" in a way that's misleading.
   DTLS packets injected into the network by an attacker who
   does not have possession of the keying materal are quite
   correctly rejected by the DTLS stack. It's just that they
   are cryptographically verified first without being rejected
   out of hand.
3. As you say, it *is* cheap, but in keeping with our general
   principle of not improving TLS but just making it datagram
   capable, we decided to stick with TLS's 0-based sequence

Not to put too fine a point on it, I think this proposed attack
s basically irrelevant. I have not heard of any situation in
which anyone has mounted DoS attacks on machines by forcing
them to repeatedly perform cryptographic packet verifications
(most likely since it's so lame) and in the unlikely case that
that were to happen, we could always quickly roll out an
extension to randomize the sequence numbers.

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

You might want to refamiliarize yourself with how these systems
actually work.

Let's take IKE as an example (though the situation is the same in
DTLS). Here's the initial exchange from RFC 4306 S 2.6.:

       Initiator                          Responder
       -----------                        -----------
       HDR(A,0), SAi1, KEi, Ni   -->

                                 <-- HDR(A,0), N(COOKIE)

       HDR(A,0), N(COOKIE), SAi1, KEi, Ni   -->

                                 <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ]

So, whenever the responder gets *any* initial packet from
a plausible counterparty (and this is clearly in control of the
attacker), it has to compute a cookie. And how is that done?
Scrolling further down S 2.6, we get some advice.

   A good way to do this is to set the responder cookie to be:

      Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

So, precisely as I said, an attacker can force the responder
to compute as many hashes as he chooses.

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.

You could call it that. I call it appropriate layering.


IETF mailing list