Re: [rtcweb] Security issue: consent refresh

[Bernard Aboba <[e-mail]>]

> And the reason you are not needing the SHA-1 stuff is that you see no
> need for this consent refresh to continue to verify that the one sending
> the answers echoing the transaction IDs is a node which you provided
> with the credentials? Or which the "evil" webservice has provisioned
> with the credentials from the signalling exchange?
> 
> Correct.  Let's assume ICE is used for initial consent.  If you're past the initial consent stage, then some far-end accepted your communication. 
>
> At that point we're at the same stage as if the JS had simply 
initiated an HTTP connection to another site and it was approved with 
CORS.  What keeps such an HTTP connection going is simply TCP 
"consent-refresh" using ACKs and not getting RST/FIN... and we don't 
need to be stronger than TCP.  Arguably the STUN keepalive would 
actually be stronger than TCP even without SHA-1, because the STUN 
96-bit Transaction-ID is harder to spoof-guess than two 16-bit TCP 
sequence number fields.
> 
> If there is a MitM physically 
on the path between the Browser and the peer, such a MitM can keep the 
RTP flowing even if we used RTCP, 
>because it could fake RTCP. (and such a
 MitM can keep TCP and SCTP going too, fwiw)


[BA] Agree with Hadriel that forcing an IWF to "manufacture" RTCP is a bad idea, and that the focus should be on an off-path attacker. 

Also agree that we need "continuing consent" and can't rely on a "source quench" approach which has proven unworkable in other
contexts. There are situations where a receiver might have "gone away" for one reason or another, or where the receiver is being 
overwhelmed, where it might not have the ability or context to tell the sender to stop.  For example, if key state has been lost, 
putting out a secured "Bye" may not be possible.