[rtcweb] Security issue: initial consent

[Hadriel Kaplan <[e-mail]>]

Howdy,
per the request made by the Chairs for threads on the security daft, I'm starting this one on the topic of initial media-stream consent.  This is related to section 4.2 and in particular 4.2.3 of draft-ietf-rtcweb-security.

With regards to initial consent, earlier proposals to use receipt of RTP from the peer as the consent have failed due to it being easy for a malicious JS site to generate a few RTP packets to accomplish it.  Earlier proposals to send some limited RTP and use receipt of RTCP Receiver Reports have failed because the entropy of RTCP RR's is too low, and thus malicious JS can spoof them too easily; there's also the problem that some legacy devices don't do RTCP. 

IF the above is true, then ISTM the only solution choices are one of the following:
1) Require ICE be used for all connections on the WebRTC Browser, and either ICE or ICE-Lite on the peer.
2) Require either ICE as above _or_ DTLS-SRTP be used for all RTP connection consent, since DTLS-SRTP handshake is sufficient consent.  In other words, if the Browser's peer uses DTLS-SRTP but not ICE, the Browser can use that as initial consent and continue.  If the Browser's peer does ICE, that provides initial consent.

Are there any others??

SDES-SRTP can't be used instead of DTLS-SRTP for such consent, because the JS will know the SDES key. 

I don't believe we need to worry about consent for purely data-stream connections, assuming we pick either SCTP/UDP, SCTP/DTLS/UDP, or TCP/UDP; because there's a handshake of sufficient entropy.  But I could be wrong about that.

I also believe there's one issue regarding consent which has not been documented: ICE-based or DTLS-based resource attacks.  If a malicious JS can trigger STUN-ICE, TURN-allocate, or DTLS-handshake messages to be sent to any destination by feeding the Browser malicious ROAP, the packet rates of those themselves can create a DDoS attack.  I think this needs to be documented so that Browsers throttle the number of such messages they generate.  ICE, for example, can mimic RTP rates during initial connectivity checks; so a malicious JS can simply cause ICE to restart often.

-hadriel