IETF Logo Mail Archive

Re: [MMUSIC] Handling of unverified data and media

Iñaki Baz Castillo <ibc@aliax.net> Sat, 11 March 2017 15:12 UTC

Return-Path: <ibc@aliax.net>
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 4DBB91294EF for <mmusic@ietfa.amsl.com>; Sat, 11 Mar 2017 07:12:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 CWjJlEbQbspR for <mmusic@ietfa.amsl.com>; Sat, 11 Mar 2017 07:12:41 -0800 (PST)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 B947E12940D for <mmusic@ietf.org>; Sat, 11 Mar 2017 07:12:40 -0800 (PST)
Received: by mail-wr0-x233.google.com with SMTP id u48so80455926wrc.0 for <mmusic@ietf.org>; Sat, 11 Mar 2017 07:12:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=blwjIL6vtGU6z2WAgUJHRdPqpPj8JezsO0tUyVvnvrk=; b=sgpsGeK69M5PBEq/mNgzdhizjZAlmtFzfivhAMr8FfYEnNqHqP8Rmo5oBMjY/79WQ7 7DuARsgMb1Tz8dax2XamZL3RPLSzYkzu0y0tH7PX9fedpI+p2K7pxfiy8gAVwL3U1Edo B9017UjQLXt7I+DdEPzwl5HJVSA4tK0SzU9fzgzmUlxhC0vy0laaktuTwDWw5hcdvb7p MmVkNMYmkILs1ASaT+4vXK7vul6SC+sALDhAV+XCCLrT578iyUXBtTtmoEy32vs6tG8d Y4if3z/Ej99NB742gsjIVj9IkSrvKY7SakJYlr9ZuhE/V/KxpQmR0FNz+sJqJOoVgJ/b jU2A==
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=blwjIL6vtGU6z2WAgUJHRdPqpPj8JezsO0tUyVvnvrk=; b=LKqiMT7OcQ88vGhrFm0+pFmXyZMxhiMkDMtbOLRA9oD1I+iLKpJZylcXFF0jZacIdQ 6Ju9XqRM5ylU9rP9mfTEyUc2HlIgskltp+Bez9V42UiTgzjevnkjyejEgTeVvlZVPdwi HAL9UslGVqrT4ilcNb9fsCnGeEqim7GH7qg0yHoU00jDS+Gm292rp4ueJ+JrLco6qULr 0sLXgZjze6Lwz0Tg+aelsXIVt8po3fSffN7z1e1bny/G1L1p0DeuLOoRBezvIQ4yITWT hlCTqRuFMplBhYMT69g5x1emUcnt64P94U/A3YoOj8PHgODvufMUU4M/sp7FOwDkCCuS ge+g==
X-Gm-Message-State: AMke39lcXyb7HUw6SXnK4V653V1h3pp6olFDeNdNlkSoBEqNyc84+ySJqumaqvEPgwDViEd9sU5S47GozmaGbw==
X-Received: by 10.223.172.135 with SMTP id o7mr19177169wrc.121.1489245159226; Sat, 11 Mar 2017 07:12:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.138.222 with HTTP; Sat, 11 Mar 2017 07:12:18 -0800 (PST)
In-Reply-To: <CAD5OKxvXTsTPaKFNdwS6tPBTAksD=jgiAFGuGMgbepOtBoFT+Q@mail.gmail.com>
References: <CAOW+2dseq8AmLKXFGUaiss8ahpkY1ZzYUD_KdirFE1rskfvqjw@mail.gmail.com> <CABkgnnUc-XsYivUzSs6W4it_Krykr-reJMDJXqKf5FvGw_NBPg@mail.gmail.com> <CAD5OKxvXTsTPaKFNdwS6tPBTAksD=jgiAFGuGMgbepOtBoFT+Q@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Sat, 11 Mar 2017 16:12:18 +0100
Message-ID: <CALiegfmyKz4JUXBoX7LaRe7U_yE2-_pbBKXHp14zm4DRSYGZgA@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/MtHH9A69C1ohfGu0ZqVmumbpGj8>
Cc: Flemming Andreasen <fandreas@cisco.com>, "hta@google.com" <hta@google.com>, mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Handling of unverified data and media
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 11 Mar 2017 15:12:42 -0000

2017-03-10 23:47 GMT+01:00 Roman Shpount <roman@telurix.com>:
> My assumption always was that data is received, decoded and discarded until
> fingerprint is received and verified. This way DTLS handshake completes, key
> frames are decoded, but user is nor presented with any unverified media.

Just imagine an app (running in a computer with public IP) which sends
the SDP offer to a server, DTLS handshake is done, and the server
sends DataChannel messages to the browser *before* the browser
receives the SDP answer.

Do you mean that such a DataChannel messages should be discarded? I
consider that catastrophic as the server may not know whether the
browser has yet received the answer or not. Apps should implement some
kind of 3-way signaling handshake (send offer, receive answer, send
ACK) before the server sends any DataChannel message.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>

v2.23.0 | Report a Bug | By Email