Re: [MMUSIC] Handling of unverified data and media

Roman Shpount <roman@telurix.com> Fri, 31 March 2017 01:11 UTC

Return-Path: <roman@telurix.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 7FFC2129541 for <mmusic@ietfa.amsl.com>; Thu, 30 Mar 2017 18:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 i1zZ5qhx_iCG for <mmusic@ietfa.amsl.com>; Thu, 30 Mar 2017 18:11:10 -0700 (PDT)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 E27841294D7 for <mmusic@ietf.org>; Thu, 30 Mar 2017 18:11:09 -0700 (PDT)
Received: by mail-pg0-x22a.google.com with SMTP id x125so54914185pgb.0 for <mmusic@ietf.org>; Thu, 30 Mar 2017 18:11:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iZli35Z70FTQrMfcGpyOst9VCf4rY5xmENKDVME5A0U=; b=QiCR7l9EBbqeNnkdSijxcGmxj+mYs2GhMZpy7Wh7qcKQPh63vrkflpkeUru4FctMWq +A0TQ2Tac1TPvfRf8/68pE3ObffJMwrWJ8xFw4JXn405vNMP+IfgqdfQYNNNNor1fDaD /BcankRya8xghGEubN7iP1t31hyG0Pkb6usnERi33sCisYNGn8vX70/wYcCvJLXCWlBO 1dQEaLQrnHAC07zb2BCDDt3nnExgGFnpdW8ThJDiUgfzo+qWF5oLXhaD+mBWGH5ZZHSs sV1DJunBNHWXd/UyzltwjOZE7wjBTtrT72+1/UHkuSwhMwKpyor4NFwAkz1DEZX7AS0d lB1w==
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; bh=iZli35Z70FTQrMfcGpyOst9VCf4rY5xmENKDVME5A0U=; b=J7SXyJGS8wuwXWB42g+kbh9AjRMoMOtPi3bGQV1MdQEnecICcy8gqlC95zf3ItSQ4H 07pkcj1lG138doJVRZ8o6q5ysRiLfWepJ1eM/uM7CogHiWdKhRVhVme61yDNctvQTdgI OgGdkgy7PiBYWW6qHIx0rh7yyHlTUsou2pFJ1iTUszvgVjkZI4PXZm34lxsgCkRvHDtE fxooib+ncD+Jp4TRex/Z8++0i80VDAfEfkEyouGUQ18QhSja6yMzxvndBAkYPOIQikqZ pcbc2b9iCqlspu+4+MJuifySnDbO65M+Q1ZCcDuSH3mIUKxjfWQWRpoqw/Vcnj5M9XCn k4OQ==
X-Gm-Message-State: AFeK/H3Cuxylh5oO5+wsv5lpzveiy+vQABuFJuE5mxnnzEXXfLBK3NWStMs59baM6HFnzg==
X-Received: by 10.98.80.93 with SMTP id e90mr257277pfb.7.1490922669241; Thu, 30 Mar 2017 18:11:09 -0700 (PDT)
Received: from mail-pg0-f48.google.com (mail-pg0-f48.google.com. [74.125.83.48]) by smtp.gmail.com with ESMTPSA id v186sm6589607pgv.44.2017.03.30.18.11.08 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 18:11:08 -0700 (PDT)
Received: by mail-pg0-f48.google.com with SMTP id 81so54941063pgh.2 for <mmusic@ietf.org>; Thu, 30 Mar 2017 18:11:08 -0700 (PDT)
X-Received: by 10.84.217.68 with SMTP id e4mr287727plj.99.1490922668014; Thu, 30 Mar 2017 18:11:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.151 with HTTP; Thu, 30 Mar 2017 18:11:07 -0700 (PDT)
In-Reply-To: <CAJrXDUG5gmgR5HQz99z9ie184SoBHuckuOEYLno-PLRm7kFniA@mail.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> <CABkgnnXcf+TVqG=W6gJmxK7424EA1nxeRmO3wA+nr7i6Viiuyw@mail.gmail.com> <CAJrXDUG5gmgR5HQz99z9ie184SoBHuckuOEYLno-PLRm7kFniA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Thu, 30 Mar 2017 21:11:07 -0400
X-Gmail-Original-Message-ID: <CAD5OKxtMLbRkm782oKw19bkOPQnxLFO71a8CK=P5pAHZ-6rBXw@mail.gmail.com>
Message-ID: <CAD5OKxtMLbRkm782oKw19bkOPQnxLFO71a8CK=P5pAHZ-6rBXw@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.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=94eb2c19f53803c657054bfc7cb9
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/MHcWiEdpaulBPu6OmvoYkZ-R0mE>
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 01:11:11 -0000

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
>
>