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

Eric Rescorla <> Fri, 11 November 2011 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BEAB21F8A71 for <>; Fri, 11 Nov 2011 06:59:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.941
X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OYBpuu2cDehT for <>; Fri, 11 Nov 2011 06:59:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AFAF121F8A6F for <>; Fri, 11 Nov 2011 06:59:54 -0800 (PST)
Received: by vws5 with SMTP id 5so4171110vws.31 for <>; Fri, 11 Nov 2011 06:59:54 -0800 (PST)
Received: by with SMTP id t14mr21457063vds.47.1321023594145; Fri, 11 Nov 2011 06:59:54 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 11 Nov 2011 06:59:13 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Fri, 11 Nov 2011 06:59:13 -0800
Message-ID: <>
To: Roman Shpount <>
Content-Type: text/plain; charset=ISO-8859-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 14:59:55 -0000

On Fri, Nov 11, 2011 at 4:02 AM, Roman Shpount <> wrote:
> On Fri, Nov 11, 2011 at 3:49 AM, Olle E. Johansson <> wrote:
o, 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.

This simply isn't "very difficult". There are existing tools for doing SSL/TLS
diagnostics and for recovering the encrypted data (e.g., ssldump, wireshark)
and it's not going to be hard to adapt them to this application.

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

I think it's important to distinguish between legacy interop and WebRTC-WebRTC
cases. I'm more positive (though still not exactly thrilled) about the
claim that we
should support RTP for interop modes provided that WebRTC-WebRTC calls are

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

There's no real need for additional verification of the remote party at the ICE
level. My suspicion is that the RTTs won't be a significant factor here, but
certainly it would be possible to embed the DTLS messages into the
ICE exchange if it turned out to be.