Re: [rtcweb] Consent alternative

[Martin Thomson <[e-mail]>]

On 29 November 2013 05:40, Magnus Westerlund
<[e-mail]> wrote:
> I have looked briefly on this and wonder if this isn't vulnerable to
> active attacks from a attacker (Alice) that likes to use a set of WebRTC
> browsers, including (Bob) to generate DDOS traffic towards the target
> (Charlie).

Hi Magnus,

I think that you did manage to hit on something critical here.

The basic security primitive in play with ICE consent is proof of
receipt.  That is the key piece at play here as well.  We require
proof of receipt simply because that elevates the requirements for an
attacker to the point that they have to basically be on-path.  At that
point, they (likely) already have the ability to generate traffic
toward a victim of an equal (or maybe greater) volume to the sender
and gain little by mounting the attack.

That's why I'm not particularly interested in the part where you talk
about attackers intercepting binding requests.

The actual attack that you have hit upon (or caused me to think about)
is not quite as you described, but it does rely on the fact that the
proposed change to the consent mechanism no longer actively depends on
proof of receipt.

It also relies on the possibility that a DTLS connection can be moved
without requiring proof of receipt on the new path.  That, to me, is
the fundamental problem to be solved.  From my reread of RFC 6347, it
appears as though the only consideration given to DoS was at the
handshake.  Once something like ICE is in play (and MICE makes this
worse), the ability to "move" the connection presents an attacker with
an opportunity.  (I have to point out that this also confirms my fears
about the mechanism used to signal ICE restarts, but I'll get back to
that.)

Here is the attack as I understand it:

1. A talks to B, establishing a DTLS connection using ICE.  There is
no need for lots of data to flow at this point, this is the "warm-up"
phase of the attack.

2. B (the attacker) triggers an "ICE restart" with A, though really
this generates a new ICE negotiation with a victim, C.  C consents to
talk to B, but not necessarily with A.  This arrangement is easy to
achieve on the drive-by web.

3. A completes ICE with C and expects to continue the DTLS connection
over the newly discovered 5-tuple.  C is confused, but really has no
recourse at this point.  Even if the DTLS connection fails, C is now
the victim on the other end of an unending stream of bits.  B spoofs
the source address of the necessary packets to continue consent, A
continues to send to C, and nothing that C does can stop the flood
because they don't have access to the master secret and cannot
therefore produce an authenticated packet that terminates the
connection.  B can continue the attack as long as A is willing, at the
bargain-basement price of a (spoofed) DTLS heartbeat response every
10-20 seconds.

The key here is the lack of a proof of receipt from A toward C for the
DTLS connection that is moved.  There is nothing inherent to DTLS that
provides proof that C received data from A and is also willing to
continue to communicate... Almost.

The DTLS heartbeat extension does provide such a thing:
http://tools.ietf.org/html/rfc6520#page-6

All we need to do to close this little loophole is to require that a
DTLS heartbeat request be sent after any change in underlying 5-tuple.
 That request MUST contain sufficient entropy that guessing would be
difficult for an off-path attacker; noting that this is also covered
by TLS record layer encryption and authentication, limiting the number
of parties that are even allowed to make a guess.  I'm a big fan of
128 bits, but less is almost certainly OK.  If no response is received
within N seconds, consent is expired.  The basic consent timer seems
appropriate here, i.e., N=30.

DTLS renegotiation would also work, but I consider that to be a little
heavyweight.  I'm not sure that it's that widely implemented either.