Re: [rtcweb] Security Architecture: IdP for RTP and RTCP

Martin Thomson <> Tue, 08 July 2014 18:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 893321A040A for <>; Tue, 8 Jul 2014 11:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_111=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fUY1GE02Ue3N for <>; Tue, 8 Jul 2014 11:09:34 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 789791A0165 for <>; Tue, 8 Jul 2014 11:09:34 -0700 (PDT)
Received: by with SMTP id x48so6324205wes.39 for <>; Tue, 08 Jul 2014 11:09:33 -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=wne8OabfCwlBACunwWcm7LKgsgKKhG2ULPyP+1XLj9A=; b=xZ2Krgch2ZBp+XvZUw3fD9x0ToL+4LKj7ReFjuQAZU7Zim6Uww4/Xdx29j7ozq0bJ+ uhCjVks7kzFd/kT7wKJKn4Sl1iy8K5RUxnEdETJQ7I2Wy+OqJBMjkT9M5Tx88I351aXv +ApBRVuViF73RX3J7C8/ugz1r36KQPmREXWVKyJrJWuuqFkHmKrL0tMsKgjFqMyai1r+ Erl4hJG1coB56ltz5ZQXrvtUb70RyskwhU9YpXTo4MQ7fwhHshx/UwaKO4DIvLc8nEc7 VMjlI348D7I+FIAMPa03ba3JosYO5eUBRgr8m0poeqwYh6OAlkwX4IABZ031oUsgmOx+ KVcQ==
MIME-Version: 1.0
X-Received: by with SMTP id ch4mr42176711wjb.59.1404842973063; Tue, 08 Jul 2014 11:09:33 -0700 (PDT)
Received: by with HTTP; Tue, 8 Jul 2014 11:09:33 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 8 Jul 2014 11:09:33 -0700
Message-ID: <>
From: Martin Thomson <>
To: Bernard Aboba <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [rtcweb] Security Architecture: IdP for RTP and RTCP
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: Tue, 08 Jul 2014 18:09:35 -0000

On 8 July 2014 10:54, Bernard Aboba <> wrote:
> In the situation where RTP and RTCP are not multiplexed, distinct DTLS
> transports and DTLS/SRTP key exchanges would occur for RTP and RTCP.
> In looking for guidance within the security architecture document, some
> questions came to mind:
> a. Are the certificates used for RTP and RTCP DTLS Transports necessarily
> the same on both the local and remote side? If they are supposed to be the
> same, what happens if they aren't?

The certificates can be different.  As you might recall, one of the
issues that we discussed was the possibility of having different
a=fingerprint attributes on different m-lines, as well as having
alternative a=fingerprint lines on the same m-lines.

The current draft handles this by covering multiple fingerprints by
the identity assertion.

> b. Can different identities be asserted for the RTP and RTCP DTLS
> Transports? Does this make sense in some circumstances? If so, when?

a=identity is a session-level attribute and they should (MUST?) only
be one.  So no.  And I can think of any case where this makes sense in
much the same way that having unmultiplexed RTP/RTCP doesn't make
sense any more (if it ever did).

> The WebRTC 1.0 API Section 8.3 seems to indicate that this should always be
> the case:
> "It is possible that different values for the "a=identity" attribute is
> provided at a media level in SDP. A browser may either choose to treat this
> as an error or ignore the attribute. If multiple different assertions are
> validated, then they must produce identical identity values."

This is out of date.  I've sent the editors a pull request to have that fixed.

> However, I am wondering whether there can be legitimate cases where a
> browser communicating with a gateway or SFU might encounter distinct
> identities or certificates for RTP and RTCP.  For example, could an SFU
> potentially terminate RTCP but not RTP, in which case the certificates and
> asserted identities might be different between RTP and RTCP?

I think that the way that we manage identity in a multi-party
situation probably needs something different to that.  I don't see any
particular value in terminating RTCP when you aren't also terminating
RTP, the two are far too tightly coupled.  They shouldn't really have
been given different names in the first place.

> The WebRTC 1.0 spec seems to indicate that this should be treated as a fatal
> error, but I'm wondering whether the browser shouldn't be "strict in what it
> sends but liberal in handling what it receives" by just using the identity
> and certificates for RTP, and ignoring the RTCP identities.  Trying to
> inform the user about different asserted identities for RTP and RTCP seems
> way too complicated to even be worth considering.

BTW, I wish that "liberal in what you permit" meme would go away.  I
haven't found it to be particularly useful, except as a fatalistic
acknowledgement of the messy end state that is the Internet.