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

Michael Procter <> Wed, 19 June 2013 12:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B412F21F9113 for <>; Wed, 19 Jun 2013 05:26:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=0.001, 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 8oOj0fAkxoQD for <>; Wed, 19 Jun 2013 05:25:59 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 4456021F8CDD for <>; Wed, 19 Jun 2013 05:25:59 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKUcGjVgFhtoPDn7or0Y/; Wed, 19 Jun 2013 05:25:59 PDT
Received: by with SMTP id hq4so609694wib.12 for <>; Wed, 19 Jun 2013 05:25:57 -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=EBPMR8wpwbBuuaEye0HBb7teU/K6Ya3yaEgWu+SoLSY=; b=caSKazLiT4Vxym0x9ORYP2aawMVO2IF8cwlOrvFKfDP1hu9hLxRSmzHmYrefXQOpIK o5jWmXGDwLXQs8w8ruGlcL/sBn+f3GR4lpy6sbqLyWBEiKZzu/9Q+s7Kj25aHY1LRBwb VYqyNqiRR0snYL9lcSek70PWm+8IlTqk0SUbVnPaTA0lSaDP9kcEfhuf6VC5IOzqdLzK bQO0Kcx77Od+hFBCrZEY44YUk2KbvzblxQb+03xXPoGQ3zSHRcZt8t8R9j04Q0Q8dpkb hcS8psiUuu/+xYIfBlDhamRS+D9yLT0keGSOZvqULCtL05Mayn6zBzy0q+RoAqolHIya dDyA==
X-Received: by with SMTP id fu9mr1983110wjb.70.1371644757440; Wed, 19 Jun 2013 05:25:57 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id fu9mr1983106wjb.70.1371644757378; Wed, 19 Jun 2013 05:25:57 -0700 (PDT)
Received: by with HTTP; Wed, 19 Jun 2013 05:25:57 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Wed, 19 Jun 2013 13:25:57 +0100
Message-ID: <>
From: Michael Procter <>
To: "Matthew Kaufman (SKYPE)" <>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQlxQA8S0EO5TftBdg7hVLm88vBK6pEYqkoOANGztlbF5gUqXDqgQm046iFZYpvYJnNRFU0PlRig6h35C/8WOjmCSG0VXbqeZCulJl4VaZG071R77aBCbXv79FBpWLDNf+8twYk5QYmmq8uSk19l2fSimsGtcg==
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 12:26:19 -0000

On 18 June 2013 22:16, Matthew Kaufman (SKYPE)
<> wrote:
> Your diagram is missing the part where the browser either learns the key
> that it is supposed to ask EKT to set or tells your SIP/SDES side what
> key it set using EKT. Either way, those keys go over HTTPS to/from the
> browser, yes?

I don't understand this part of your argument.  I was under the impression that
using DTLS-EKT meant we could avoid having keying information visible to
Javascript in the browser whilst still interoperating with legacy SRTP UAs that
determine their own transmission keys.

In your example, I thought it would work like this:

your PBX <-(SDES in SIP)-> my sip server <-(??)-> my media relay
<-(DTLS-EKT)-> browser

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.

Yes, there is some call control coordination to do between the web server
and the sip server/media relay, but no keying information needs to pass to
the web server, nor on to the Javascript running in the browser.

Have I missed a use-case?  Is there a requirement to set the browser's
transmission key to a specific value (in which case, you are correct that
it would have to pass over HTTPS at least) too?