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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF8D721F84AC for <>; Fri, 11 Nov 2011 00:49:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.121
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H-NDnxX5jtaM for <>; Fri, 11 Nov 2011 00:49:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 52A9921F84AA for <>; Fri, 11 Nov 2011 00:49:43 -0800 (PST)
Received: from [] ( []) by (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" <>
In-Reply-To: <>
Date: Fri, 11 Nov 2011 09:49:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <4EBC4401.20> <>
To: Roman Shpount <>
X-Mailer: Apple Mail (2.1251.1)
Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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

"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.