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

"Muthu Arul Mozhi Perumal (mperumal)" <> Thu, 20 March 2014 03:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D4E471A034F for <>; Wed, 19 Mar 2014 20:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1t2q40nW3MvK for <>; Wed, 19 Mar 2014 20:41:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 15C741A0345 for <>; Wed, 19 Mar 2014 20:41:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2304; q=dns/txt; s=iport; t=1395286910; x=1396496510; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4vZ3nJ61py903WgSAvFHMjKP51K2HsKMeU09ceBvIW8=; b=J+0C4T9HSM5qgGKgta0v9BD+3mX+OxWOT91StVhFFrCFUqAGPaJoxae6 6CLrLL24tlhGBZRQ2j5pDIR901nmOv+bID8K3iqbKeqdOiYGCXS1NQAGu 7IUMCyeECpuL6Wb1RxL6uB5Y2MVZznBu4X5YGl6Q23d/PiYZ5WiV3U4gg M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.97,691,1389744000"; d="scan'208";a="28878213"
Received: from ([]) by with ESMTP; 20 Mar 2014 03:41:49 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s2K3fnHR017119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 03:41:49 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 22:41:49 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" <>
To: Martin Thomson <>
Thread-Topic: [rtcweb] Should consent checks be optimized further?
Thread-Index: Ac9Ddg2wwxMgoYNeSLCvKCoxDf8YUwAU3gmAAAiUahA=
Date: Thu, 20 Mar 2014 03:41:48 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] Should consent checks be optimized further?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Mar 2014 03:42:01 -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.


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