Re: [rtcweb] No Interim on SDES at this juncture

Michael Procter <> Wed, 19 June 2013 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56F0621F84F2 for <>; Wed, 19 Jun 2013 08:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LKVhNTWNi+bK for <>; Wed, 19 Jun 2013 08:00:53 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id C25EB21F8517 for <>; Wed, 19 Jun 2013 08:00:51 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKUcHHmS+qQmqh/; Wed, 19 Jun 2013 08:00:51 PDT
Received: by with SMTP id t56so4504979wes.21 for <>; Wed, 19 Jun 2013 08:00:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+tYKxv4w4ocPPMrUWA5hwxwWv3yql5Ltbpl/sUy6qu8=; b=UcCEgw6hHbyBLhGnYQzUrqjeTgxO0iEJNwhaYo7a4fuCcyyCnt0UpKsAIPXw9Y6nQK lRZlr39aQxTbpiHHVJGhTI4CYyIBXs6fsUpPVyfxNpBB6KylXngV/qlU8wYvKE6IWXHY RL1wIpkN8MWR02W/Ckggd8wv6SlLhh9tJJ9q3RgeSWVG+sK0kPvZN6SIeUmo5GWVXuj7 pufShUMhqSW2pPc26Izlf2YLeETcBt4jaAQphFBBLGxACiAZTr6oAOoxNwVHJWm1ypia OiqQ+2smDCK2c0Owky5KV4rQzaQsHTLL5+gFFvS7+tGWXZk0tBDqFeI+CmV5Wg63b+1d 8New==
X-Received: by with SMTP id xk16mr10447930wib.62.1371654040415; Wed, 19 Jun 2013 08:00:40 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id xk16mr10447923wib.62.1371654040278; Wed, 19 Jun 2013 08:00:40 -0700 (PDT)
Received: by with HTTP; Wed, 19 Jun 2013 08:00:40 -0700 (PDT)
In-Reply-To: <BLU169-W121182C4C5CB47B68868E1B938D0@phx.gbl>
References: <> <> <> <> <> <> <> <> <> <> <> <BLU169-W121182C4C5CB47B68868E1B938D0@phx.gbl>
Date: Wed, 19 Jun 2013 16:00:40 +0100
Message-ID: <>
From: Michael Procter <>
To: Bernard Aboba <>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQm2licKY9kID0l4mj7ZLZMHSXSCJVDYP55YWg7E+UhQN+07zm9uO0V+K5wX3VbNFNSEDVTcAx+LVNuIajCu9aDVsAA5U+XPJaG21Sx7HYrFU3qPPoutwfWqzZAbh1nyZmjuE0KpcM1RwUmgHci2HDLY612ccQ==
Cc: "" <>
Subject: Re: [rtcweb] No Interim on SDES at this juncture
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: Wed, 19 Jun 2013 15:00:59 -0000

On 19 June 2013 14:46, Bernard Aboba <> wrote:
> Michael said:
>> The PBX chooses its transmission key, and advertises it through
>> SDES/SDP. The browser chooses its transmission key and advertises it
>> through DTLS-EKT. The media gateway has the job of matching up the
>> SDES pieces with the EKT pieces, and thereafter forwarding packets.
> [BA] Since the PBX can only handle SDES, and the media server speaks
> DTLS/SRTP-EKT,  the media server needs to provide the DTLS/SRTP-EKT
> key to the SIP server so that it can be signaled to the PBX within SDES/SDP.
> Similarly, the SIP server needs to provide the SDES key signaled by the
> PBX to the media server so that it can communicate this in DTLS/SRTP-EKT.
> Therefore the PBX, media server, SIP server and browser endpoint
> end up possessing the keys, which is less than ideal.

Well indeed.  The point I was querying was Matthew's assertion that the keys
also needed to be available to the web server and the Javascript app in the
browser (and hence transferred over HTTPS), for both SDES and EKT approaches.

I don't see why this should be true for EKT, which therefore
highlights a fairly
significant (IMHO) difference in the security properties of an
EKT-based solution.

I'm not currently claiming a preference for one over the other, but I think this
difference should be considered in the context of the whole picture.