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

Roman Shpount <> Fri, 11 November 2011 12:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 77D3321F8593 for <>; Fri, 11 Nov 2011 04:02:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BNvp1757YShB for <>; Fri, 11 Nov 2011 04:02:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 596D621F8548 for <>; Fri, 11 Nov 2011 04:02:35 -0800 (PST)
Received: by gye5 with SMTP id 5so3382694gye.31 for <>; Fri, 11 Nov 2011 04:02:35 -0800 (PST)
Received: by with SMTP id g20mr5666387ani.73.1321012954603; Fri, 11 Nov 2011 04:02:34 -0800 (PST)
Received: from ( []) by with ESMTPS id f32sm33149203ani.20.2011. (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Nov 2011 04:02:33 -0800 (PST)
Received: by ywt34 with SMTP id 34so2215119ywt.31 for <>; Fri, 11 Nov 2011 04:02:32 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id b10mr24056389pbi.18.1321012951954; Fri, 11 Nov 2011 04:02:31 -0800 (PST)
Received: by with HTTP; Fri, 11 Nov 2011 04:02:31 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Fri, 11 Nov 2011 07:02:31 -0500
Message-ID: <>
From: Roman Shpount <>
To: "Olle E. Johansson" <>
Content-Type: multipart/alternative; boundary=bcaec520f2afbeb61904b1744be8
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 12:02:36 -0000

On Fri, Nov 11, 2011 at 3:49 AM, Olle E. Johansson <> wrote:

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

Also, I wanted expand on the debug requirements: I do hope we will make key
exchange mechanism, different from SDES, mandatory for WebRTC. Passing
actual encryption keys through JavaScript makes media encryption to easy to
circumvent. This means some type of public/private key encryption used for
key exchange. If we do this right, getting to the actual key used for media
session encryption will be very difficult, so most of the tools currently
used for SRTP debugging will stop working. We will also end up with
something new, which will mean extensive need for debugging. Ability to
turn this component on and off will be very helpful for implementation
debugging. Once again, this will probably be not a critical point, but
making something easier for developers usually goes a long way in driving
the adoption.

One more benefit of having RTP as fallback for legacy interop is that it
will allow us to specify something that will be more secure for WebRTC. If
SDES support would no longer be needed, we can concentrate on using key
exchange mechanism that is actually secure.

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
Roman Shpount