Re: [MMUSIC] Handling of unverified data and media

Cullen Jennings <> Fri, 31 March 2017 15:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4FE71299BD for <>; Fri, 31 Mar 2017 08:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.695
X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EVnA83mah7sJ for <>; Fri, 31 Mar 2017 08:52:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D94211294C0 for <>; Fri, 31 Mar 2017 08:52:42 -0700 (PDT)
Received: from (localhost []) by (SMTP Server) with ESMTP id 3CDA657E7; Fri, 31 Mar 2017 11:52:39 -0400 (EDT)
Received: by (Authenticated sender: with ESMTPSA id BFF2159A1; Fri, 31 Mar 2017 11:52:38 -0400 (EDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by (trex/5.7.12); Fri, 31 Mar 2017 11:52:39 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_B8202525-3F1C-4305-BEEA-C08E79738311"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Cullen Jennings <>
In-Reply-To: <>
Date: Fri, 31 Mar 2017 10:52:37 -0500
Cc: Christer Holmberg <>, mmusic <>
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Peter Thatcher <>
X-Mailer: Apple Mail (2.3124)
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 15:52:51 -0000

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):
> 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.
> 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.
> 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
> <>
> <>