Re: [rtcweb] Benjamin Kaduk's Discuss on draft-ietf-rtcweb-security-11: (with DISCUSS and COMMENT)

Adam Roach <adam@nostrum.com> Wed, 06 March 2019 19:29 UTC

Return-Path: <adam@nostrum.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 56AE513120D; Wed, 6 Mar 2019 11:29:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level:
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnOKlYSClVqM; Wed, 6 Mar 2019 11:29:07 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391F413120B; Wed, 6 Mar 2019 11:29:07 -0800 (PST)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x26JSxJ2079174 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Mar 2019 13:29:05 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551900546; bh=yaVoPuLdWUsSQGHdgWo7uVOzAxCvcsjg4W82M+ACqlM=; h=From:Subject:To:Cc:References:Date:In-Reply-To; b=MxFSxoW/u2/u2YsUWhBDKmbgk7d9eLuCeCju5PN8cmSFke3BHP3h0DA0tAW4trDmV JRNZWAcwx4ZzTkAk+FrS0oKSxdoitVnTDFyGUkXWnbc0EnUYfQWg9neirW6pIWQM0o lZlWNSJXhan7+6TgIIYCYH03/+QYL+S41jZdtUhk=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
From: Adam Roach <adam@nostrum.com>
To: Datatracker on behalf of Benjamin Kaduk <ietf-secretariat-reply@ietf.org>, The IESG <iesg@ietf.org>
Cc: draft-ietf-rtcweb-security@ietf.org, rtcweb@ietf.org, rtcweb-chairs@ietf.org, sean@sn3rd.com
References: <155189932716.14137.9903426522882898659.idtracker@ietfa.amsl.com>
Message-ID: <83e273b7-09b8-6560-097b-9410c2f8f9fd@nostrum.com>
Date: Wed, 6 Mar 2019 13:28:53 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.2
MIME-Version: 1.0
In-Reply-To: <155189932716.14137.9903426522882898659.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/sGDFfr1_W8cGjjnncQ9pDJE8MBQ>
Subject: Re: [rtcweb] Benjamin Kaduk's Discuss on draft-ietf-rtcweb-security-11: (with DISCUSS and COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 06 Mar 2019 19:29:08 -0000

I wanted to quickly respond to the two discuss questions you have.

On 3/6/19 1:08 PM, Datatracker on behalf of Benjamin Kaduk wrote:
> Mutually-verifiable "secure mode" seems to require that the peer's browser be included in
> the TCB, which is a bit hard to swallow.  Are we comfortable wrapping that in alongside
> "we trust the peer to not be malicious"?


You are correct that this is part of the assumption of the model, and 
the reason it makes any sense at all is that the "attacker" of concern 
here is a web app. To mount an attack with the current assumptions, a 
malicious app would need to somehow compel a user to install a malicious 
browser platform prior to using its app.

Another way of thinking about this is: unless we are going to require 
the validated use of a crytographically secured operating system with 
signed, secure audio and video drivers that require HDCP, running on 
Trusted Computing hardware, then we need to draw a line somewhere, 
beyond which the media is considered in a "safe enough" environment.


> It's not clear how much benefit we can get from *optional* third-party identity providers;
> won't the calling service have the ability to silently downgrade to their non-usage even if
> both calling peers support it?


The notion here is that the web browser itself provides indicia that 
mean "this media is secure and being sent only to <remote party's 
identity>" in a way that web pages cannot. So you are correct that it's 
up to the web app to opt-in to this feature; but whether they do so is 
user-visible. So, e.g., if you host a service that claims its media 
cannot be intercepted (e.g., in the style of Signal, Wire, or WhatsApp), 
users can trivially verify whether such a claim is true.

/a