Re: [rtcweb] Consent alternative

[Dan Wing <[e-mail]>]

On Dec 2, 2013, at 2:44 PM, Martin Thomson <[e-mail]> wrote:

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

Requiring sending an ICE request (and receiving an ICE response) would also _almost_ work -- that is, when remote party claims to change their IP address not only is an ICE request from their IP address needed, but also need to send an ICE request to their new IP address and get an ICE response (same as you are saying to send them a DTLS heartbeat to their new address).  To thwart that, an ICE attacker would need to be on-path and we could envision places where B (the attacker in your enumerated list above) is on a shared network with C (victim), such as shared WiFi.  DTLS heartbeat prevents that attack because B (the attacker) doesn't know the necessary secrets to generate the DTLS heartbeat message (whereas with ICE, B would know the ICE username and ICE password).  If I have all that correct for how ICE consent could be attacked, it shows a security advantage of DTLS consent over ICE consent.

-d


> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb