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

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 19 Mar 2014 15:01:49 +0000

Though the WG's decision is to go with the STUN consent mechanism (draft-ietf-rtcweb-stun-consent-freshness) instead of the DTLS consent mechanism (draft-thomson-rtcweb-consent), I think the later raises a question that we haven't discussed in the context of the former, yet:

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?

Here, authenticated traffic could be DTLS-SRTP or DTLS-SRTCP or data-channel or STUN binding requests.

Some of the reasons why we may not want to do such optimization:
- To keep the mechanism simple.

- To not introduce layering violations.

- Might help network elements to piggyback metadata about change in network

  conditions to other network elements and endpoints (in line with what

  Matthew in the meeting).
- The overhead of performing consent freshness compared to processing actual
  traffic is generally minimal.
- Might help in calculating RTT for the data channel (that doesn't have RTCP).

- Introduces a security weakness: SRTP is encrypted and authenticated with

  symmetric keys; that is, both sender and receiver know the keys. With two

  party sessions, receipt of an authenticated packet from the single remote

  party is a strong assurance the packet came from that party. However, when

  a session involves more than two parties, all of whom know each other's

  keys, any of those parties could have sent the packet. Such shared key

  distributions are possible with some MIKEY [RFC3830] modes,

  Security Descriptions [RFC4568], and EKT [I-D.ietf-avtcore-srtp-ekt].

On the other hand, there might be some constrained networks that allocate fixed bit rate for traffic and the occasional consent checks could break that fixed bit rate. This looks the only benefit of not performing consent freshness when receiving authenticated traffic.

It should be noted that draft-ietf-rtcweb-stun-consent-freshness already has the following:

   When not actively sending traffic on a nominated candidate pair,
   performing consent freshness does not serve any purpose from a
   security perspective.

Which itself is good optimization, I think.

Comments welcome..

Muthu

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Mar 2014 11:18:23 -0700

On 19 March 2014 08:01, Muthu Arul Mozhi Perumal (mperumal)
<[email-masked]> 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.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 20 Mar 2014 03:41:48 +0000

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:[email-masked]]
|Sent: Wednesday, March 19, 2014 11:48 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]
|Subject: Re: [rtcweb] Should consent checks be optimized further?
|
|On 19 March 2014 08:01, Muthu Arul Mozhi Perumal (mperumal)
|<[email-masked]> 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.