Re: [rtcweb] Which servers to trust (Re: Consensus call regarding media security)

Randell Jesup <randell-ietf@jesup.org> Tue, 03 April 2012 12:35 UTC

Return-Path: <randell-ietf@jesup.org>
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 7A53B21F879D for <rtcweb@ietfa.amsl.com>; Tue, 3 Apr 2012 05:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.272
X-Spam-Level:
X-Spam-Status: No, score=0.272 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_40=-0.185, SARE_MILLIONSOF=0.315]
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 4jSJsadDPfrb for <rtcweb@ietfa.amsl.com>; Tue, 3 Apr 2012 05:35:15 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A4FC121F8764 for <rtcweb@ietf.org>; Tue, 3 Apr 2012 05:35:15 -0700 (PDT)
Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1SF2x8-0001hQ-1g for rtcweb@ietf.org; Tue, 03 Apr 2012 07:35:14 -0500
Message-ID: <4F7AEDB6.8000907@jesup.org>
Date: Tue, 03 Apr 2012 08:31:50 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4F732531.2030208@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E221877@inba-mail01.sonusnet.com> <4F749C82.4070305@infosecurity.ch> <4F7ACC96.90206@alvestrand.no> <CALiegf=jJ6SfQhbxPXKdDDKqp7bOrpRNVE=RfBs8Ah8zqy9ftQ@mail.gmail.com>
In-Reply-To: <CALiegf=jJ6SfQhbxPXKdDDKqp7bOrpRNVE=RfBs8Ah8zqy9ftQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Which servers to trust (Re: Consensus call regarding media security)
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: Tue, 03 Apr 2012 12:35:16 -0000

On 4/3/2012 7:55 AM, Iñaki Baz Castillo wrote:
> 2012/4/3 Harald Alvestrand<harald@alvestrand.no>:
>>> SDES-SRTP provide a very reliable and simple way to let a WebRTC peer to
>>> establish security with the server, assuming that it already have
>>> established security trough HTTPS/TLS that's a consolidate trust method.
>>
>> The term "the server" is a fallacy. The Web server and the media gateway (if
>> there is one) are likely not the same server, and may even be operated by
>> different entities.
>> SDES-SRTP forces you to trust both.
>
>
> If you trust the Web server (i.e. due to HTTPS usage with a valid
> server certificate) then you will also trust that the Web server will
> not signal your WebRTC communication to a malicious destination, am I
> wrong?

Partly.  First, as you mention, the site can be hacked.  Another issue 
is that you may NOT trust the website to avoid tapping your 
communication (and in fact they may be legally obligated to do so, and 
have no choice in the matter).  Also, as shown by Diginotar, website 
certs can be forged transparently if a CA is hacked.  Those are both 
real-world cases where you cannot trust the site you connect to via 
https to secure your data (in addition to "the site was hacked", even if 
they are "trustworthy".

> Don't take me wrong but, which kind of security obsession are we
> trying to satisfy in rtcweb? a media communication is not more
> important than a web access to my back website in which I enter my
> credit card PIN. Does IETF define "security standards" for POS ("Point
> of sale terminal") for making a bank payment via a 3rd web
> (e-commerce)? AFAIK not.

No, but other organizations define such standards in great detail - and 
still there are weekly breaches of security that require credit card 
companies to send out thousands or millions of replace cards & numbers.

And a site providing media communication will not have the ultra-strict 
security reviews and audits that come with processing credit card info, 
and so is much more likely to be hacked.

> If the Web server (assuming HTTPS) is trusted and SDES-SRTP used, we
> should trust the communication. If it fails that is because the Web
> server has been attacked. If that occurs, it's really worse the case
> in which my bank website has been attacked (I'm giving my credit card
> PIN to the attacker).

It can be far worse - most people are given guarantees about how much 
they can lose (often $0) - a hassle is all usually; sometimes a big 
hassle, but not harmful personally.  Media interception (especially 
video) can cause horrible repercussions in some cases - blackmail, 
embarrassment, scandal, and in countries like Iran or cases like the 
Arab Spring, jail or death.


-- 
Randell Jesup
randell-ietf@jesup.org