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

"Olle E. Johansson" <oej@edvina.net> Fri, 11 November 2011 08:49 UTC

Return-Path: <oej@edvina.net>
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 DF8D721F84AC for <rtcweb@ietfa.amsl.com>; Fri, 11 Nov 2011 00:49:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 H-NDnxX5jtaM for <rtcweb@ietfa.amsl.com>; Fri, 11 Nov 2011 00:49:43 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 52A9921F84AA for <rtcweb@ietf.org>; Fri, 11 Nov 2011 00:49:43 -0800 (PST)
Received: from [192.168.20.63] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id 6D04C754BD08; Fri, 11 Nov 2011 08:49:39 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <CAD5OKxuaWJ3SBv+0gac6EQy6-Lsb-LS_SBXk5FqObKy4mN6wNg@mail.gmail.com>
Date: Fri, 11 Nov 2011 09:49:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CCF4FC92-D5AA-43C8-A0B2-8041C9B8E1BD@edvina.net>
References: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@mail.gmail.com> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.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> <4EBC4401.20 90703@alvestrand.no> <CAD5OKxuaWJ3SBv+0gac6EQy6-Lsb-LS_SBXk5FqObKy4mN6wNg@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: rtcweb@ietf.org
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 08:49:44 -0000

10 nov 2011 kl. 23:07 skrev Roman Shpount:

> 
> 
> On Thu, Nov 10, 2011 at 4:37 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
> So far, we've heard arguments that:
> 
> - encryption uses more CPU (true, but arguably not significant compared to media processing)
> - It is needed for legacy interoperability (may be true for some, but not necessarily compelling)
> - It helps debugging (which has been disputed by people who debug systems)
> 
> Did I miss some?
> 
> 
> Encryption being illegal in some situations is yet another reason (I know about the IETF position on wiretapping, but I would still argue that this is a valid reason.)
> 
> Higher barrier to entry for building new services -- for instance if you are building a media server to work with WebRTC client. Having one more thing to implement before something works is not critical, but makes a difference.

If you support DTMF in RTP you already have a requirement that you SHOULD  only do that over SRTP. If rtcweb supports telephony-events, we are already on the SRTP side as almost mandatory. I think it's easier to reach an agreement on SRTP being mandatory than DTMF being dis-allowed.


Appendix A of RFC 4733:
"The Security Considerations section is updated to mention the
   requirement for protection of integrity.  More importantly, it makes
   implementation of SRTP [7] mandatory for compliant implementations,
   without specifying a mandatory-to-implement method of key
   distribution."

"The telephone-event payload defined in this specification is highly
   compressed.  A change in value of just one bit can result in a major
   change in meaning as decoded at the receiver.  Thus, message
   integrity MUST be provided for the telephone-event payload type.

   To meet the need for protection both of confidentiality and
   integrity, compliant implementations SHOULD implement the Secure
   Real-time Transport Protocol (SRTP) [7]."

Section 6 of RFC 4733 - an RFC that makes 2833 obsolete.


/O