Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06

Martin Thomson <> Fri, 21 February 2014 17:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8A1FF1A02D0 for <>; Fri, 21 Feb 2014 09:34:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.797
X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FREEMAIL_FROM=0.001, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fnfczqqlxbZt for <>; Fri, 21 Feb 2014 09:34:02 -0800 (PST)
Received: from (unknown [IPv6:2a00:1450:400c:c00::233]) by (Postfix) with ESMTP id 089AC1A01DC for <>; Fri, 21 Feb 2014 09:34:01 -0800 (PST)
Received: by with SMTP id n12so2709929wgh.18 for <>; Fri, 21 Feb 2014 09:33:57 -0800 (PST)
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=V4WZH1KYk62iVfQJu4SN7BbQU4+4ePAi7VajdpDk4WM=; b=gAIhJFNeQOO4Yfir3/n78C6pW4zbGiKXn4x9g+V90eLbmEbgTJQ+nrq54q1Mn0n+3n rFVOiWDLBdrXhtjHjBkSdj2d83eK4/oOZMm/YrfPel3dStsAASw9GDeRRM/POOeN+7Xd eZ9VloGEie3VKUFtNwJHB/DIBsL9UAhTQF1/YiHynJBJXh1iTddern73muLUqnEs3s1I 3Xzh4d4LqKQGA+OvNG9V7K+L2OXbxuD1/Zo1aWn40L+9G0U1K8uvx3uAien0cb5DSf8z 0kd0xmXlPGC4GHiTCIXDjy2ai8377WvUEyeE5ifnt09FgVB4dGd0B69RvnAxg3KJhaS+ 98Ow==
MIME-Version: 1.0
X-Received: by with SMTP id hx9mr8428107wjb.28.1393004037356; Fri, 21 Feb 2014 09:33:57 -0800 (PST)
Received: by with HTTP; Fri, 21 Feb 2014 09:33:57 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Fri, 21 Feb 2014 09:33:57 -0800
Message-ID: <>
From: Martin Thomson <>
To: Magnus Westerlund <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06
X-Mailman-Version: 2.1.15
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, 21 Feb 2014 17:34:03 -0000

On 20 February 2014 08:05, Magnus Westerlund
<> wrote:
> When I read this section, my immediate question was, doesn't RTP need
> corresponding protection. To my understanding, the answer would be yes,
> but it is more difficult to inject data and get a certain plaintext even
> without the SRTP encryption scrambling the payload part. Still, that
> assumes that an JS application, can write the payload data itself.
> Secondly, it does assume that one MUST use encryption in SRTP.

Yes, with WebAudio, I can construct an SRTP packet that contains
ciphertext that I can control, assuming that I know the session keys
(yes), and I'm prepared to do a lot of work.  SRTP doesn't have the IV
per-packet that DTLS does.  What you can't do is make it look like a
non-SRTP packet, the first byte, length and MAC would be extremely
difficult to control (for the MAC, that's more or less the point...),
if not impossible.

So the question is, is there an intermediary that might be tricked
into interpreting an SRTP packet in a way that might have negative
consequences.  When masking was added to websockets, it was because
the confusion was demonstrated as being possible: intermediaries were
searching for HTTP requests and responses in ways that were easily
exploited and then caching the results.  To a large extent, that
attack relied on the fact that TCP is a stream-based protocol - it
didn't matter where the request appeared.  In this case, the mapping
of SRTP onto UDP doesn't really lead to intermediaries looking for
goodies inside packets.

I'm not going to say that there is a risk, but I think that I'd be
willing to take the risk given the plethora of mitigating
circumstances here.