Re: [MMUSIC] Handling of unverified data and media

Martin Thomson <martin.thomson@gmail.com> Thu, 30 March 2017 22:50 UTC

Return-Path: <martin.thomson@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 4348B1296CD for <mmusic@ietfa.amsl.com>; Thu, 30 Mar 2017 15:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_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 hj8rpqSsuvzL for <mmusic@ietfa.amsl.com>; Thu, 30 Mar 2017 15:50:46 -0700 (PDT)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 AF83912945D for <mmusic@ietf.org>; Thu, 30 Mar 2017 15:50:38 -0700 (PDT)
Received: by mail-qk0-x235.google.com with SMTP id r142so53592552qke.2 for <mmusic@ietf.org>; Thu, 30 Mar 2017 15:50:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MDUz8K9wiBAA9Q9NaY0LPbjNamnAPuLtiPM+0XvQ+78=; b=ogufXd7k22a7BTaC7GlbUEQt1qmnqs8t/+Bad5UQnDecMUSlfsq3AYwaxOsfyKOyve wB+HqBtIq8JNn34RZofotWQfi+lZ4GfUirLKCztD0zhS62dCvLAorEm+ZGI+W+LuRqyR U8TG/pmcHEeMH5uLd7/lCYzGxjWaZncjMq5FmsIi5PtDY15MowNrryDV/5GxKPWkP9UJ IEXfy4pSv0pp5Ti/sK2NFL0v67nlZqRR1aSClgXmVUrOiT0p8a8fUV7vn3f2up0O/gEm oPrNNGs93L6z+LUWeyAsfoty9jl6Kbb7JNgRevTvzOlTIczrF7VgtwU0Fd/ryHSRGR5/ 8tyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MDUz8K9wiBAA9Q9NaY0LPbjNamnAPuLtiPM+0XvQ+78=; b=IbZa/tnHtu6eaMq8a0xMGUZDgIrOCXOPr2HBYaDpL8a/ypnOZmtLo4Hw4Hme9lRPy8 7ZE4taR0bfWFqe+4cNGajUq/xxQoH0QM7g/5KLxlcAB3ujiCPX4FROaBQXuHLAHYOMSj jrntRu3yQkM42cHvaMBtHFYxW6B6WI4+HAVfbyFM4E1O1R6fJzdiv+WFquf0fV1bl2pz 6sY8HBVH8KO78ppEDi/SQvtYKcHEYjTLHBjykrzSdPGo/LeA5OlqnrcdnPFHZS6xhJ8g z/SLl4ut53OkcEQ56enqSvX2r2Xh3NGA/FunsKiNeI72a9NCNeNolPOqzMrU9IkJPLBY xSlw==
X-Gm-Message-State: AFeK/H1AEv3ztbW7EaDK3qPUwvmL7tTHtcveTux+bMSXWCjYcb85OVdwC94Os+VlpxPM88FiZv+iFxgp/6Dngw==
X-Received: by 10.55.126.195 with SMTP id z186mr2352453qkc.144.1490914237900; Thu, 30 Mar 2017 15:50:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.27.194 with HTTP; Thu, 30 Mar 2017 15:50:37 -0700 (PDT)
In-Reply-To: <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> <E427CC84-257A-4894-9B81-E8A46F824B2A@gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 30 Mar 2017 17:50:37 -0500
Message-ID: <CABkgnnXcf+TVqG=W6gJmxK7424EA1nxeRmO3wA+nr7i6Viiuyw@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: Peter Thatcher <pthatcher@google.com>, mmusic <mmusic@ietf.org>, Cullen Jennings <fluffy@iii.ca>, Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/6eh7Ai1rw7mtqbQ6b47N9sFEX38>
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:50:48 -0000

These both sound like legitimate cases where ICE can precede
signaling.  I would recommend that the W3C think carefully about
whether they might like to accept (potentially) invalid data before we
spend a whole lot more time on the issue.

On 30 March 2017 at 17:11, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> 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
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>