Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)

Randell Jesup <randell-ietf@jesup.org> Fri, 11 November 2011 18:46 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 7A66621F8AF2 for <rtcweb@ietfa.amsl.com>; Fri, 11 Nov 2011 10:46:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level:
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599]
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 xId+iiBXtpkg for <rtcweb@ietfa.amsl.com>; Fri, 11 Nov 2011 10:46:38 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 3860121F8A97 for <rtcweb@ietf.org>; Fri, 11 Nov 2011 10:46:38 -0800 (PST)
Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] 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 1ROw7Z-0000K1-BB for rtcweb@ietf.org; Fri, 11 Nov 2011 12:46:37 -0600
Message-ID: <4EBD6D63.4090209@jesup.org>
Date: Fri, 11 Nov 2011 13:45:55 -0500
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@mail.gmail.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <CALiegfmf59jb4asUu9LA6YY_aMtKEnM1Wy34KbuLEn3_h1xBXA@mail.gmail.com> <CALiegfmM1PB=VAQjfh4rW3-3C8aumHdWy9nZxD0-BWBq9Kq_tg@mail.gmail.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <CALiegfkWnRT8m4S9pXTxuLsc-p_bhkG3d=PX3qgiFFt5gW5yfw@mail.gmail.com> <CAD5OKxvQYVKOZF88WLCiRseg-qXQdOpKeDU_t9b-yA2GcDBT-w@mail.gmail.com> <CABcZeBOiPxz_swdaG6Aqoch1WAUtjNh4eOQy1QObCDXT_B8azg@mail.gmail.com> <CAD5OKxtp+LQBRCHgbWdJyrSRcpNQ82i64TJgGtGPrE7+GKcEog@mail.gmail.com> <4EBC3475.90706@alvestrand.no> <CAD5OKxu_-+ZRsqpUBkFSj=tYtOKG0pK3JoQTZHwQGMuBCnp0Gw@mail.gmail.com> <CAD5OKxuaWJ3SBv+0gac6EQy6-Lsb-LS_SBXk5FqObKy4mN6wNg@mail.gmail.com> <CCF4FC92-D5AA-43C8-A0B2-8041C9B8E1BD@edvina.net> <CAD5OKxs-pWwDBjwAu=mQVWRZa4H_YPpzQ31=0qxUUj-pJOErcg@mail.gmail.com> <A2DFC694-DBDF-4DB4-8DE0-DD638C7AF2BE@acmepacket.com>
In-Reply-To: <A2DFC694-DBDF-4DB4-8DE0-DD638C7AF2BE@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)
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: Fri, 11 Nov 2011 18:46:39 -0000

On 11/11/2011 8:38 AM, Hadriel Kaplan wrote:
> On Nov 11, 2011, at 7:02 AM, Roman Shpount wrote:
>
>> Well, this is a perfect example when specifying mandatory security for wrong reasons is simply being ignored. All the reactions I've seen to this so far were "this is only a SHOULD, let's disregard this for now". Getting security requirements in the standard which are too high too be practical usually produces products which disregard security completely, reaching the exactly opposite effect. I think, in this particular case, the right course of action is to use AVT tones in RTP as the rest of the industry is doing now.
> I think using in-band tones in RTP for DTMF instead of 4733 would be a really bad idea.

+10.  Let's not even discuss that option further.

>> Finally, (going slightly off topic here) it would probably be a good idea to make key exchange part of the initial ICE transaction. This way we can use this key exchange as an additional verification of the remote party, and reduce the number of round trips required before the media flow is established.
> That's an interesting idea.  The extra round trips of DTLS-SRTP, added to those of ICE, have had me worried about clipping when the user answers the call.  It's been an advantage of SDES not to worry about that.

Anything we can do to minimize clipping and reduce startup RTTs is a 
*very* good thing.  We should start seriously analyzing this as we're 
getting down to more specifics.

And recent privacy breaches have shown that otherwise-good pre-warming 
of connections and pre-negotiation of codecs may be problematic from a 
security point of view - exchanging ICE candidates with an incoming 
OFFER from your abusive ex-boyfriend might tell them where you are 
(local IP), though it would be possible for people not wanting to 
disclose their address to *require* a TURN proxy be in use and not offer 
local IP, limiting the leaked information.  This does require proactive 
selection of safety by the user, a risky proposition.

As a possible compromise, you could force TURN for the pre-start of the 
call and if accepted, renegotiate with real local addresses.  Might 
cause a glitch though if you're not careful.

-- 
Randell Jesup
randell-ietf@jesup.org