Re: [MMUSIC] Handling of unverified data and media

Peter Thatcher <pthatcher@google.com> Fri, 31 March 2017 17:59 UTC

Return-Path: <pthatcher@google.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 8A2281243F3 for <mmusic@ietfa.amsl.com>; Fri, 31 Mar 2017 10:59:41 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 nCeXJ-NowEEe for <mmusic@ietfa.amsl.com>; Fri, 31 Mar 2017 10:59:38 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 D6F83129435 for <mmusic@ietf.org>; Fri, 31 Mar 2017 10:59:37 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id p22so73225829qka.3 for <mmusic@ietf.org>; Fri, 31 Mar 2017 10:59:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lyVlGQjF3+lKyZg28YOufvyPo0IBdOq6H1xvGrCE9eo=; b=O5qpzQgVqtvzTQFwfIjvVYy00uo3x8b8iuYd5P3oENHrKQGiq4BCzd5TZwZGB4BTL+ 7CMN4fsWOSEAO1T1PwuFe1ytCGGx1z4s+fx2RweWS5mXxkQeSdKZqaDQBcgFThKadJLX n4rY+Dc1GB+aXK0qpDFW2nI1yVeAW65ZDQ/s+lQfrxqak6yz1CV0S8bB+DCk/ZZuMF4J YUYB54rZqm868WMpovEBNGXV5KJ6xX8yNrsqlAz3auAZUBKfcOFwmvjTJP8sRUMiQWLr Y/Av4cbic6valSI1f5wzMH5AelcBcQRFUH7GZG8mgxw7yozgl8lrue4JIVLh29iXeHCa YLWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lyVlGQjF3+lKyZg28YOufvyPo0IBdOq6H1xvGrCE9eo=; b=RUFP5HWG/4EtKZywkAzS1kBiZspzC/zzc4bT7IE64kfsf51cr2is3RCVb0LbAn2l2h wpIH/Crm/51shA5uzYh9evVlXGk/YEHx8I7wpvQYBzwCQ9aOqQyfcmavQLOWiQ72KzGd 3hp1o9u6t9dK5elUFbTyKOQ+GNxnp4iWz6JZfm4GClMfyfRTjBTjTOVv30HPGvaYGFcE 6vHcyA0FAVMUNGdZcaklo594NWMSw4zriUDp5rXbnFRUMYeCUiQ3yel2xkaXtbYrmyMo 8pVkHq70G3dl4OStqUMQAM0dRH1U2rILEveDQ6sS73MYXfBhwIAnlpJm98G/Q8naYtH2 oo+w==
X-Gm-Message-State: AFeK/H10+wyXprE/Ulttfp+cHr3oUDeYJMNZ1X8V7qLOAX5Y4e3iAe561vZd8RdTweDoXPRdpKXm37hxZq1vm9Bd
X-Received: by 10.55.20.234 with SMTP id 103mr3648632qku.200.1490983176850; Fri, 31 Mar 2017 10:59:36 -0700 (PDT)
MIME-Version: 1.0
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> <CABkgnnXcf+TVqG=W6gJmxK7424EA1nxeRmO3wA+nr7i6Viiuyw@mail.gmail.com> <CAJrXDUG5gmgR5HQz99z9ie184SoBHuckuOEYLno-PLRm7kFniA@mail.gmail.com> <CAD5OKxtMLbRkm782oKw19bkOPQnxLFO71a8CK=P5pAHZ-6rBXw@mail.gmail.com>
In-Reply-To: <CAD5OKxtMLbRkm782oKw19bkOPQnxLFO71a8CK=P5pAHZ-6rBXw@mail.gmail.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 31 Mar 2017 17:59:25 +0000
Message-ID: <CAJrXDUEJ4DoD1i2pO8MEmuCu9FAhjahghXFAcdaVvWAmDSt2Eg@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Bernard Aboba <bernard.aboba@gmail.com>, mmusic <mmusic@ietf.org>, Cullen Jennings <fluffy@iii.ca>, Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=001a11400ff09fb6a4054c0a9296
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/bRcClsujSxoRuL6WaJXUHuj0CzA>
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: Fri, 31 Mar 2017 17:59:41 -0000

If the full ice endpoint receives an offer, it has the remote DTLS
fingerprint, so no problem on that

It's true that the ice lite endpoint will be able to receive media from the
full ice endpoint before it receives the DTLS fingerprint of the full ICE
endpoint.  So you are correct that this is an issue for ice lite endpoints,
just as it is for non-ICE endpoints.




On Thu, Mar 30, 2017 at 6:11 PM Roman Shpount <roman@telurix.com>; wrote:

> Peter,
>
> What about ICE lite? If ICE lite sends an offer to WebRTC end point, it
> can get DTLS ClientHello before it got the answer response from the WebRTC
> end point. Since ICE lite client does not send ICE requests before sending
> data, it will respond with ServerHello and establish the connection. At
> this point data can be sent to it before the answer arrives and fingerprint
> can be verified.
>
> I think the right answer to this situation is not to send ServerHello
> until answer and fingerprint is received. ClientHello should be buffered
> and only handled when answer is received.
>
> Regards,
>
> _____________
>
> Roman Shpount
>
> On Thu, Mar 30, 2017 at 7:40 PM, Peter Thatcher <pthatcher@google.com>;
> wrote:
>
> Bernard, you are right that this is possible with ORTC, even though I
> think it's impossible with WebRTC.  But that's clearly out of scope for the
> MMUSIC WG.  Perhaps the right forum to discuss Cullen's 1-800-fedex use
> case is in the context of ORTC (or WebRTC NV).
>
> On Thu, Mar 30, 2017 at 3:50 PM Martin Thomson <martin.thomson@gmail.com>;
> wrote:
>
> 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
> >
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>