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

Martin Thomson <> Fri, 14 June 2013 04:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5432F21F9AF8 for <>; Thu, 13 Jun 2013 21:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id niTFfvNl2Bda for <>; Thu, 13 Jun 2013 21:50:53 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::229]) by (Postfix) with ESMTP id 860AD21F9AE5 for <>; Thu, 13 Jun 2013 21:50:53 -0700 (PDT)
Received: by with SMTP id n57so89589wev.0 for <>; Thu, 13 Jun 2013 21:50:52 -0700 (PDT)
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; bh=xHpH7QJgjY0m5BjuUEhfi9gud7SVSlR9aG+d5fFDLmo=; b=XN5Q9yr3xToYj69pXCb1P1b0/v5Dhi4oVkpoOpQvF/jZrydazV4yAfYyPXs2i/VzwX tl6AbkCXw4dLGe2bOBU5CsEmFeOIPe9kEsvchDx7Z1CJJb6RxJi+oSGQBwtCam1HTgKC PJONI+cqXlZGfDYGYSNnWO96Q5wj4QAZ3b6wiqPfakZW/xsFF86fVNc3nfhWCR1xjBj8 i1dIXwGMpaNZ27hjTJqgBRcBrVA37qbGKfOyYro/DUMuOGI9s9uKg4bMeInGFpjnUV2i 2B8nUHp7oW0YDJ8tgulOI9VqTnlZLIMrY+/VnGLln1XAblLMJBiVm3ShNoFiOGXl0Qh9 6A2Q==
MIME-Version: 1.0
X-Received: by with SMTP id ww2mr342069wjb.3.1371185452652; Thu, 13 Jun 2013 21:50:52 -0700 (PDT)
Received: by with HTTP; Thu, 13 Jun 2013 21:50:52 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Thu, 13 Jun 2013 21:50:52 -0700
Message-ID: <>
From: Martin Thomson <>
To: Hadriel Kaplan <>
Content-Type: text/plain; charset=UTF-8
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: Fri, 14 Jun 2013 04:50:54 -0000

On 13 June 2013 20:39, Hadriel Kaplan <> wrote:
>> My impression from Paris was that if the WebRTC world supports EKT, then gatewaying into an SDES realm requires some fancy key-shuffling, nothing more.
> My impression from the discussion there was: "we have this new shiny toy no one's ever deployed so why don't we use you as the guinea pig".  In fact if I recall correctly it was you who said something along those lines in Paris. :)

Likewise.  I also wonder what the API surface for this feature needs
to look like.  Clearly, someone needs to decide to push new keys into
the session, but can that be the application: is this something that
would have an API in the browser?

(That's a serious question, BTW.  Comment 22 provided that interface,
because we wanted to support SDES and the same interface conveniently
applies to EKT, but that leads to some interesting issues with respect
to media security.)

As I see this issue, it's a not a matter of "do we need SDES in
addition to DTLS-SRTP", it's more a matter of "how do we solve the
my-MCU-is-on-fire problem", for which there are two proposals on the
table: SDES and EKT.  The latter has some issues with respect to
deployment, even if it has some merits from a security perspective.
There are other reasons that SDES is preferable to us, though those
might not be compelling to others, but I can't get over this central