IETF Logo Mail Archive

Re: [MMUSIC] Handling of unverified data and media

Bernard Aboba <bernard.aboba@gmail.com> Thu, 30 March 2017 22:11 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C91127863 for <mmusic@ietfa.amsl.com>; Thu, 30 Mar 2017 15:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylI96zucKTXa for <mmusic@ietfa.amsl.com>; Thu, 30 Mar 2017 15:11:20 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D7E12426E for <mmusic@ietf.org>; Thu, 30 Mar 2017 15:11:19 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id l7so28903431ioe.3 for <mmusic@ietf.org>; Thu, 30 Mar 2017 15:11:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GPS2apr1Yfj4MGk49KgcMbRPzJSby7xmA2ZjuvMKWmw=; b=CNtycJABYlAskIhwLRihcnHKMWduTbJXstI6+ISyPnhNrAlkft9JpUH2kNrCxoPrCO JFT8zCjrqh1Wwbg8tkYQ+gWGO+ccdu0wEQFSVraWxRsy1/jSTCHL2IgxrsflfGGfwS0i XtIjAz2XXbh9S5baLF3m6twjCl48NZu/Dv+XQm5u6829EmjVPb1+bOyuDc4FDDXeiss5 3hCPDObQUkS6UoRWh0Fovqsu/cX6pHYO60VWfQReMP+lyAu/BMfa4N0XFFGmvv6f0kzy HyGuzoXgJFOQJTWSNAw22gThuq0oUINiq35/6FvTq5VZOsw6D8PqmH0WWRIFpwG8y00n TJ5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GPS2apr1Yfj4MGk49KgcMbRPzJSby7xmA2ZjuvMKWmw=; b=Kx9vx463U8BQnizlCMCpSVhlbTyiM3c4SY5xh5RcpURAQ0LvdCnxcFAaMEXJ+a0+pV 0mUI1lHagf2FAqtC+vccBknk85cUQfEqdqIzQe79iAQH6nCkoKvD/IsIC3p9nXShjBax is5BvcBmJzptoIaFddjw0soJnUOIygYtPBoGOibNPdcz0UsgzxNTlgblMK2Qm44WCMaO /58vGMR8T1FYZ84oEkUtbCxsLTanh6MmPMBaAMp95YI7qZ4dwFB1giwrWeCOdgW7/iHl UdNh/Tq9zZ5tfQeU4++aCDg1RVSw2SpbQU3pZr/qKx3iVrezXfial/HoVmcBMomuiFVZ tu3A==
X-Gm-Message-State: AFeK/H0QVTHu/vai7A8BTocEhklEk71Bi16edxwMFdNMPqEjGi78thUr4SrfmioMiUjLoQ==
X-Received: by 10.107.19.142 with SMTP id 14mr3336327iot.188.1490911879295; Thu, 30 Mar 2017 15:11:19 -0700 (PDT)
Received: from [31.133.150.38] (dhcp-9626.meeting.ietf.org. [31.133.150.38]) by smtp.gmail.com with ESMTPSA id p198sm224786itg.31.2017.03.30.15.11.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 15:11:18 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-A847AEEA-3DD6-490F-BCF2-F5A0B89A0EC5"
Mime-Version: 1.0 (1.0)
From: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: iPad Mail (14D27)
In-Reply-To: <CAJrXDUGy10nV3bWYsiLFc0czu5ydmwU-uf9AC=O+zfUxken+=w@mail.gmail.com>
Date: Thu, 30 Mar 2017 17:11:17 -0500
Cc: Cullen Jennings <fluffy@iii.ca>, Christer Holmberg <christer.holmberg@ericsson.com>, mmusic <mmusic@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <E427CC84-257A-4894-9B81-E8A46F824B2A@gmail.com>
References: <CAOW+2dseq8AmLKXFGUaiss8ahpkY1ZzYUD_KdirFE1rskfvqjw@mail.gmail.com> <CABkgnnUc-XsYivUzSs6W4it_Krykr-reJMDJXqKf5FvGw_NBPg@mail.gmail.com> <CAD5OKxvXTsTPaKFNdwS6tPBTAksD=jgiAFGuGMgbepOtBoFT+Q@mail.gmail.com> <CABcZeBO9MP0fqg=ubpgU8+3L9koB5grCyp-O8hS9Pis942-rhA@mail.gmail.com> <CAOW+2due+uNyWn-3GQnpXrR-L55XVZSXXRmC0E9-5BSGKynUYA@mail.gmail.com> <CABcZeBPr4OjUBSUdS3wWmUuRJh7XmgxfVaY1F15mjMAqjbTZRg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> <CF91D618-CC36-4811-A1BE-CAC48EF66900@iii.ca> <CAJrXDUGy10nV3bWYsiLFc0czu5ydmwU-uf9AC=O+zfUxken+=w@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/kORF5xfYumR3WrY3quHWqcLnK48>
Subject: Re: [MMUSIC] Handling of unverified data and media
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 22:11:22 -0000

The unverified media scenarios seem to depend on ICE connectivity being bi-directionally enabled so as to permit the DTLS negotiation to proceed in advance of remote fingerprint arrival. If ICE candidates are signaled separately from the DTLS fingerprint exchange it might be feasible, such as in ORTC signaling where the ICE parameters are exchanged before the DtlsParameters.

At the last WebRTC interim a scenario involving PRANSWER and Trickle ICE was presented. In the scenario, the PRANSWER included a fingerprint, but possibly one which did not match the certificate provided in DTLS unlike the final answer. I do not see how this could work but perhaps I am missing something.

> On Mar 30, 2017, at 14:14, Peter Thatcher <pthatcher@google.com> wrote:
> 
> We have a mailing list discussion (here), a bug (https://github.com/w3c/webrtc-pc/issues/849) and a PR (https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215) 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 <fluffy@iii.ca> wrote:
>> 
>>> On Mar 13, 2017, at 3:44 PM, Christer Holmberg <christer.holmberg@ericsson.com> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

v2.23.0 | Report a Bug | By Email