Re: [rtcweb] Consent freshness - revisiting the RTCP option

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Wed, 09 May 2012 07:35 UTC

Return-Path: <mperumal@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767A021F849A for <rtcweb@ietfa.amsl.com>; Wed, 9 May 2012 00:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.574
X-Spam-Level:
X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPEXSn1+E2Kn for <rtcweb@ietfa.amsl.com>; Wed, 9 May 2012 00:34:59 -0700 (PDT)
Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5943A21F8491 for <rtcweb@ietf.org>; Wed, 9 May 2012 00:34:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2384; q=dns/txt; s=iport; t=1336548899; x=1337758499; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6SliWO4zQ+OEjgDi0O+wjManBKR6F8s6kApHj7gfygI=; b=Vz30egN1EOPDIv1VjNzFem1F5MLO1dk+qhhr9lJM8LGDROu3cXjMJeFb hlYkvhp66HiLlLxnQUHgAc0qgyrL7LAPc6clSwhatpOA5uuDdFr9aYcdC TXm4KxFempheDWedp+eJZvRCFmahUyitjnICspmLflMJ/e92D1ejPcJbA 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap8EAJEdqk9Io8UY/2dsb2JhbABEtEeCDAEBAQQBAQEPAR0KNAsMBAIBCBEEAQELBhcBBgEmHwkIAQEEAQoICAEZh2wLmnugMIsMGYUWYwSIYptzgWmCcYFOBwER
X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="11770981"
Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 09 May 2012 07:34:57 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q497YvPo024040; Wed, 9 May 2012 07:34:57 GMT
Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 May 2012 13:04:57 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 09 May 2012 13:04:56 +0530
Message-ID: <1D062974A4845E4D8A343C65380492020865B735@XMB-BGL-414.cisco.com>
In-Reply-To: <4FAA150C.5020301@alvestrand.no>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Consent freshness - revisiting the RTCP option
Thread-Index: Ac0tsNqCEaA9e71pQsqr9NpOv87TXwAA46mg
References: <4FA99618.9050700@alvestrand.no><CABcZeBMqGdKEFsxncK0fuVJnpyR2_hDbdfmcH4wTz_x-Q1iPUA@mail.gmail.com> <4FAA150C.5020301@alvestrand.no>
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Harald Alvestrand <harald@alvestrand.no>, Eric Rescorla <ekr@rtfm.com>
X-OriginalArrivalTime: 09 May 2012 07:34:57.0084 (UTC) FILETIME=[3B99B7C0:01CD2DB6]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Consent freshness - revisiting the RTCP option
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 09 May 2012 07:35:00 -0000

More reasons why RTCP may not be suitable for consent freshness:
1. RTCP (as described in RFC3550) is receiver based, so the browser
can't explicitly request for consent. If consent freshness fails (for
e.g, RTCP packets temporarily lost because of network flapping), the
browser would have to wait for the peer to send RTCP before it can start
transmitting media. Worst, if the peer isn't an active sender it may not
send any RTCP RR until it receives media. It could send a bare minimum
RTCP RR (an RR with RC=0 and SDES with CNAME), but that has zero
entropy:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01497.html

2. There are still some endpoints that don't send / pay attention to
RTCP:
http://www.ietf.org/mail-archive/web/rai/current/msg01257.html

For these cases an intermediary like an SBC would have to manufacture
them. Manufacturing them for just consent freshness would be expensive
compared to generating STUN request/response.

Muthu

|-----Original Message-----
|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
Behalf Of Harald Alvestrand
|Sent: Wednesday, May 09, 2012 12:26 PM
|To: Eric Rescorla
|Cc: rtcweb@ietf.org
|Subject: Re: [rtcweb] Consent freshness - revisiting the RTCP option
|
|On 05/08/2012 11:59 PM, Eric Rescorla wrote:
|> On Tue, May 8, 2012 at 2:54 PM, Harald
Alvestrand<harald@alvestrand.no>  wrote:
|>> Just because I realized I didnt understand something, I ask.....
|>>
|>> We rejected RTCP RR as a consent freshness mechanism because RR is
trivial
|>> to fake.
|>> But - now we have SRTP as mandatory-to-use, which means that all
RTCP RRs
|>> are integrity protected, origin authenticated and replay protected
(do I
|>> have that right?).
|>>
|>> What is the reason why this is not sufficient protection to use RTCP
RR as a
|>> consent freshness mechanism?
|> This isn't a complete analysis, but if you are using SDES for key
management,
|> then the site knows the SRTCP keys, so I don't *think* SRTCP is
buying you
|> much. I haven't thought through this completely though, so maybe
there is
|> still some additional value.
|Ah - had forgotten that the attacker is assumed to observe the
|signalling path. Thanks.
|
|_______________________________________________
|rtcweb mailing list
|rtcweb@ietf.org
|https://www.ietf.org/mailman/listinfo/rtcweb