[rtcweb] Should consent checks be optimized further?

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Wed, 19 March 2014 15:02 UTC

Return-Path: <mperumal@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8B0DB1A045A for <rtcweb@ietfa.amsl.com>; Wed, 19 Mar 2014 08:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.047
X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id d_ayqiTkqmVr for <rtcweb@ietfa.amsl.com>; Wed, 19 Mar 2014 08:02:01 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id B01F11A0743 for <rtcweb@ietf.org>; Wed, 19 Mar 2014 08:01:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10885; q=dns/txt; s=iport; t=1395241311; x=1396450911; h=from:to:subject:date:message-id:mime-version; bh=wat5GepDK6kl5g4z7XshlFgPeCQrBQI+R8h2f22A5NI=; b=ON5JPT0HQe9JAKzueRnxOW095IU+3D5kWCzza1jBCauEckaffImRFiMV ItS247RRtR3is1VBxQj75+yEvT8RD5a3la7+mAfqNZAdxwuy2W87I2x9Z 9cJMrWD7Ds1ro24/z09mJitvFrhJ1F/Ng3MihECfi+iz+HHMYDqRY0DJ6 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFABCwKVOtJV2Y/2dsb2JhbABagkJEO1fCRYEZFnSCJwEELV4BKlYmAQQbh3GeFbFLF440g1yBFASqd4Mtgis
X-IronPort-AV: E=Sophos; i="4.97,686,1389744000"; d="scan'208,217"; a="311410363"
Received: from rcdn-core-1.cisco.com ([]) by rcdn-iport-6.cisco.com with ESMTP; 19 Mar 2014 15:01:51 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com []) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2JF1oJG025879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <rtcweb@ietf.org>; Wed, 19 Mar 2014 15:01:50 GMT
Received: from xmb-rcd-x02.cisco.com ([]) by xhc-rcd-x03.cisco.com ([]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 10:01:50 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: Should consent checks be optimized further?
Thread-Index: Ac9Ddg2wwxMgoYNeSLCvKCoxDf8YUw==
Date: Wed, 19 Mar 2014 15:01:49 +0000
Message-ID: <E721D8C6A2E1544DB2DEBC313AF54DE22E319CE5@xmb-rcd-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE22E319CE5xmbrcdx02ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9R14AOH8lwaTDloITduU_PB6Cvk
Subject: [rtcweb] Should consent checks be optimized further?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Mar 2014 15:02:02 -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..