Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]

Randell Jesup <randell-ietf@jesup.org> Tue, 01 November 2011 20: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 83BDC11E81CA for <rtcweb@ietfa.amsl.com>; Tue, 1 Nov 2011 13:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 PM1ZDh5RWxhR for <rtcweb@ietfa.amsl.com>; Tue, 1 Nov 2011 13:35:49 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 14BE811E8091 for <rtcweb@ietf.org>; Tue, 1 Nov 2011 13:35:48 -0700 (PDT)
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 1RLK19-0001ny-QV for rtcweb@ietf.org; Tue, 01 Nov 2011 14:29:03 -0500
Message-ID: <4EB0486E.2040001@jesup.org>
Date: Tue, 01 Nov 2011 15:28:46 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <CALiegfnVaZjh1K+brd180Z9Ufheau3v6OJe6Ejv8P7wzw6ROQw@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <CAD5OKxu=3FvnUDV5m1TW8n+7D+B6ihp_g7TXKtJVaVW3gtiySQ@mail.gmail.com> <4EAC24A2.70401@alvestrand.no> <4EADBAD3.5020804@mozilla.com>
In-Reply-To: <4EADBAD3.5020804@mozilla.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] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]
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, 01 Nov 2011 20:35:49 -0000

On 10/30/2011 5:00 PM, Timothy B. Terriberry wrote:
>> If we support SDES, the offer also contains crypto keys. Reusing crypto
>> keys for all created connections would be a huge security vulnerability.
>
> I'm starting to come to the opinion that we shouldn't support SDES. If
> we're doing it just for interop with legacy, we'd get better interop
> with fewer headaches by supporting plain RTP. We'd have a distinction
> between the two that I could actually explain to users, and less chance
> of (unnoticed) downgrade attacks.

SDES causes all sorts of privacy and security risks, so long as we 
retain the threat model of not trusting the JS or server, so unless we 
either a) relax the threat model, or b) allow SDES only in place of no 
encryption for non-rtcweb/webrtc destinations - i.e. never between 
rtcweb clients.  The downside would be a downgrade attack where the JS 
routes the call through a relay-and-copy server that acts as a legacy 
gateway.

My position is no SDES unless someone convinces me there's a need for it 
and it doesn't add important security risks/holes.  While SDES is the 
"most" common keying method currently (and least secure in most cases!), 
there are more keying mechanisms for SRTP than I can count/remember.

-- 
Randell Jesup
randell-ietf@jesup.org