Re: [MMUSIC] Handling of unverified data and media

Peter Thatcher <> Fri, 31 March 2017 17:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1596129869 for <>; Fri, 31 Mar 2017 10:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y4fO5haz-au2 for <>; Fri, 31 Mar 2017 10:36:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07B941299A1 for <>; Fri, 31 Mar 2017 10:36:10 -0700 (PDT)
Received: by with SMTP id n21so71452535qta.1 for <>; Fri, 31 Mar 2017 10:36:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lqtfg/oZs9deqqaMpZe7xRhXY2QMzbenC6jCNJo+sFY=; b=SAKygK8l22/5Oy5CYONSCiTZvqpKnDJYUwQSoDmKg9r8OPdn6bmbmFCBue/Aa5Ugd0 fUhNYGYuB4aa0BEtR4+GnJ/bYtcmCp5O82VVq8XS+B3VPcwJbk45CkdKMn0Ma2liJfBd /0CbHRAvAKT7UFjjdJY5AFj5UMUpff7KoYxzk3I2rXW2Um+lo9DObXLr4hKAMAUYm94W TM39g9edn03cBjFE227keD+uXKCS/fi8UCa/zy/+OrBxK/oWCEh22TI3PDSR4oeh0KOM CX+7dG5VNakbI2TDkdod8GOYN7q9qvz+l6fjTSpF7j26d+3znPjIvxCzrGmsOHKcElhr 5edA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Lqtfg/oZs9deqqaMpZe7xRhXY2QMzbenC6jCNJo+sFY=; b=HUrD7IpQc2GCoRfi7I3xx2l6RuaAuKZcZTL5CUg5W95NOFVGJufXcEUlUkALqqNsUu uoFlZRyMEqRWNtRCSAAwIXq895xiZ4sl99K/Vn/qzHS93/XULKFvMNPO+kYmnfUuoeMq YylbTUWvC2IYPWctiAo1kFxiajD0WK2+BldEl+5o0Pf9zBX0KAONxOFl7BylUyOb/q2e qxfwLM/Lb4rSAeHihnILulDSfeuCR4sbBSVu2dZi47bo6kayAHi7IHA3K8/uk1TUVe3M qLEgLBZq92vhWDY806j7TVasQ7YDf13H0YNFlQW5ZZx5vTFcypUmKDyJTg4KmbvJEBMs TOvA==
X-Gm-Message-State: AFeK/H1byYspcpNukRPhNSeoZwAUB0hpMXhGBtnu0X8HS2Fmd3anGr703oo2KblT56SLqaa0htLmGNJ9ShUtQhg+
X-Received: by with SMTP id r50mr4383178qtc.46.1490981768875; Fri, 31 Mar 2017 10:36:08 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Peter Thatcher <>
Date: Fri, 31 Mar 2017 17:35:58 +0000
Message-ID: <>
To: Cullen Jennings <>
Cc: Christer Holmberg <>, mmusic <>
Content-Type: multipart/alternative; boundary="001a113c7148b3b090054c0a3e6c"
Archived-At: <>
Subject: Re: [MMUSIC] Handling of unverified data and media
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Mar 2017 17:36:13 -0000

How did ICE+TLS "come up" butween A and S without A knowing S's ICE
ufrag/pwd, and thus S's fingerprint?  I assume it does know S's fingerprint
before it can decrypt any media from/through S.

Now are you suggesting that the remote fingerprint be changed to G's
fingerprint?  In that case, a new DTLS handshake would take place, but only
after A know's G's fingerprint.

In both cases, A knows the fingerprint before being able to decrypt
incoming media.

The only way to be able to decrypt media before having the remote
fingerprint is if you can receive the ICE ufrag/pwd before the  DTLS
fingerprint.  And with WebRTC/JSEP, it's impossible to get the ICE
ufrag/pwd before the DTLS fingerprint.  Changing to a second/different
fingerprint after that doesn't change anything.

On Fri, Mar 31, 2017 at 8:52 AM Cullen Jennings <> wrote:

> Imagine a WebRTC browser called A sends an offer to a SBC called S.  S
> sends PR offer accepting data channel but not others. ICE comes up between
> A and S. A TLS channel comes up between A and S. S forwards the offer to
> gateway called G over SIP with no ICE. G sends a TLS connection to A that
> is relayed via G. So this new connection is in the same ICE context. The
> ICE goes between A and S. But the 2nd TLS goes between A and G but gateway
> by S.
> I realize a more complete description would be useful but hopefully that
> is enough to think about a bit.
> On Mar 30, 2017, at 2:14 PM, Peter Thatcher <> wrote:
> We have a mailing list discussion (here), a bug (
> and a PR (
> about
> this.  I've copied the following comments to the latter two, so I'm adding
> them here as well.
> TL;DR: I don't think unverified media is compatible with ICE+DTLS.  Here
> is why (you can go see the bug, too):
>    1.
>    You can *receive* DTLS from the remote side before receiving the
>    remote description (and thus fingerprint). This happens if the remote side
>    sends an ICE connectivity check and the local side sends a response and
>    then the remote side sends a DTLS packet.
>    2.
>    You cannot *send* DTLS from the local side before receiving the remote
>    description (and thus fingerprint). This is because you can't send an ICE
>    connectivity check until you have the remote ICE ufrag and pwd, and thus
>    can't get an ICE connectivity check response, and thus can't send DTLS.
>    This is because you can't send anything other than ICE until you get an ICE
>    connectivity check response.
>    3.
>    Since you can't send DTLS, you can't complete the handshake, and thus
>    can't extract the SRTP key.
> Maybe I'm missing something, but I think this is impossible.
> On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings <> wrote:
> On Mar 13, 2017, at 3:44 PM, Christer Holmberg <
>> wrote:
> My question is: is this something that’s causing problems in real
> deployments, and requires a change in the standard?
> 1-800 go fedex. See webrtc requirements documents from many years ago.
> _______________________________________________
> mmusic mailing list