Re: [MMUSIC] Handling of unverified data and media

Martin Thomson <> Thu, 30 March 2017 20:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 542DC129569 for <>; Thu, 30 Mar 2017 13:50:49 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 eNllJPn836l4 for <>; Thu, 30 Mar 2017 13:50:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 72A97129544 for <>; Thu, 30 Mar 2017 13:50:43 -0700 (PDT)
Received: by with SMTP id r45so50195143qte.3 for <>; Thu, 30 Mar 2017 13:50:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2qrrFXjw5W/3pJMfSIhgZAbO0znszDwx44t0mxBvH6E=; b=YCcyV9iBdt7l2U/Mtg+08hw2J1GFg4PHsUm+GuAU0NdOGX1oBy5ydfIYfpRdXmdP6o 155bQInHFjLuRjLuVQcP381Q3jppo3pYVz2ZKjoj5zZOmbq/5YwNlYYBofVV6eav7bLk p5HulgQAO5utvKOTg1lHiJYMChF5PdrA2RNWXYIwMGzld8em8+2WY2XRkmv1gy6CzCyJ GUkPwcV8AuxdM9dD1HWPuNLxbDY8D1qz8NESwdiM4zuxssCrlmKBPnDRrv2ylCcZGLWC h+ALNuuTXd6vhGQKlkjYh4jUQQ+cli6Kc+xQDbT3KS4xcrIl1XPrhAunzKQ7lDpEhzc2 J1hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2qrrFXjw5W/3pJMfSIhgZAbO0znszDwx44t0mxBvH6E=; b=tFzLA+O4uJrSklFy0CZCT4U9AfPbL1A16uxs7MgFTOp6OaPxG9/VwRxm4ld/wQguAz zl7AjMLwxQpTIzCkGUP1Pr45Pucbl9UdWNzQEpQSJPCaMJfvNsqXqADTIdvrWTqsmYhq UBW9uINZwPkHG66RakixIsM46qTczPGgvqkOYo/m0xgdJO78HW5fUAEippNP0Oq+Va+5 FKVy8KX5E1g3Kgty0Bnjpx1IRjz1mOde6trIAj9KfyMCeWoZa57WfT3VOrZep+j9b379 Xwlm6VJ3dxeIr51d27u6lHRTpDERzJCskjQTmKbxFM2+Cse3pP9IBwHcG0PRvjgnk6bN lA4g==
X-Gm-Message-State: AFeK/H0zyI2iRc5n8xLQON3DXUuRVVXer5T36Y8YwMtPwSD0RS50qwdqwC26nss9TKKBpIAb4oZPWx35mDEOQQ==
X-Received: by with SMTP id s27mr1987572qta.278.1490907042496; Thu, 30 Mar 2017 13:50:42 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 30 Mar 2017 13:50:42 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Martin Thomson <>
Date: Thu, 30 Mar 2017 15:50:42 -0500
Message-ID: <>
To: Peter Thatcher <>
Cc: Cullen Jennings <>, Christer Holmberg <>, mmusic <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Thu, 30 Mar 2017 20:50:49 -0000

Tim had a comment that didn't make it due to time, but I thought that
it was worth forwarding here:

<derf> What I was getting up to say was, I think it's "acceptable" to
provide the data to the application if and only if the application has
a way to know that it's (potentially) invalid (and when it becomes
<derf> What would _not_ be acceptable would be to provide the data to
the application in a way that's indistinguishable from receving valid

In terms of what policy the *browser* application takes towards this
data, it would seem unwise to pass anything concrete to the origin.
Media might be isolated, but that leads to it being essentially
equivalent to mixed content.  the W3C might be ... let me just say
reluctant ... to add new ways of adding mixed content to the web.

On 30 March 2017 at 14:14, 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
> _______________________________________________
> mmusic mailing list