Re: [rtcweb] Security issue: initial consent

[Hadriel Kaplan <[e-mail]>]

On Oct 27, 2011, at 7:44 PM, Matthew Kaufman wrote:

> On 10/28/11 12:39 AM, Hadriel Kaplan wrote:
>> ...
>>   Heck, we could even mandate using a new TCP header option to be reflected by the other side, similar to the TCP Timestamp option, but put a random number in it.
>> 
> 
> Again, the STUN connectivity test used by ICE does more than simply prove that the far end got the packet and can reflect it back. The reflection isn't even done unless the long-term credentials are valid.

Yes I know the ICE/STUN user/pass proves a shared secret, but what attacker/attack are you protecting against?

The JS obviously knows the ICE secrets, so the secret does not prevent the JS from spoofing to cause a hammer attack - only the reflected trans-id does.

A MitM may not know the secret, but if we didn't do ICE, what advantage could the MitM gain by responding to the TCP SYN or DTLS handshake?  If it's a MitM it can allow ICE to succeed anyway end-to-end, and then respond to the TCP SYN or DTLS.  

And I'm not suggesting just because they have a handshake that it makes TCP/UDP or SCTP/UDP secure from MitM eavesdropping or impersonation.  ICE doesn't either obviously.  I'm only saying that it makes it hard for a *non-MitM* to spoof.  

The main concern was that a malicious JS can cause a hammer/DDoS attack on another target, without being a MitM of the media-plane.  That's particularly difficult given RTP/RTCP have no handshake; or more to the point UDP has no handshake.  DTLS, TCP/UDP, and SCTP/UDP have it.  The question is if they're entropic enough to prevent the malicious JS from spoofing the handshake when it's not a MitM on the media-plane.  If the JS *is* a MitM on the media-plane, then the JS doesn't gain much by making the Browser perform the attack since the JS is now being attacked too.

No?  Maybe I'm missing something basic.

-hadriel