Re: [rtcweb] Should consent checks be optimized further?

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

Good point. That would require diving into the key exchange and authentication mechanism used for the reverse traffic, introducing more layering issues.

I think explicitly requesting for consent whenever there is some traffic to be sent is much simpler and neater than indirectly inferring it based on the traffic received and trying to fix the security loopholes. The former not only keeps the functionality confined to the STUN module (thus easier to maintain), but also ensures it has wider applicability -- even while receiving unauthenticated traffic. In addition, I don't see any big savings if we infer it based on the traffic received.

Muthu

|-----Original Message-----
|From: Martin Thomson [mailto:[e-mail]]
|Sent: Wednesday, March 19, 2014 11:48 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [e-mail]
|Subject: Re: [rtcweb] Should consent checks be optimized further?
|
|On 19 March 2014 08:01, Muthu Arul Mozhi Perumal (mperumal)
|<[e-mail]> wrote:
|> Should reception of authenticated traffic from the peer on the inverted
|> 5-tuple be considered as peer granting consent to send traffic to it? Should
|> the browser refrain from performing consent freshness when it continues to
|> receive such traffic from the peer?
|
|
|You forgot to mention another concern here, which is that the receipt
|of an authenticated packet is not sufficient if the path has changed.
|You need to verify that the peer on the new path has both consented to
|receive data AND is in possession of the session keys.  Otherwise, in
|combination with source IP/port spoofing, you get an attack that a
|victim cannot opt out of.