[rtcweb] Should consent checks be optimized further?

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

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