IETF Logo Mail Archive

Re: [MMUSIC] Handling of unverified data and media

Cullen Jennings <fluffy@iii.ca> Sat, 11 March 2017 21:40 UTC

Return-Path: <fluffy@iii.ca>
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 E15221295DD for <mmusic@ietfa.amsl.com>; Sat, 11 Mar 2017 13:40:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 EnVClMRCMO70 for <mmusic@ietfa.amsl.com>; Sat, 11 Mar 2017 13:40:37 -0800 (PST)
Received: from smtp122.iad3a.emailsrvr.com (smtp122.iad3a.emailsrvr.com [173.203.187.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11EAE1295DF for <mmusic@ietf.org>; Sat, 11 Mar 2017 13:40:35 -0800 (PST)
Received: from smtp32.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 196FC5762; Sat, 11 Mar 2017 16:40:35 -0500 (EST)
X-Auth-ID: fluffy@iii.ca
Received: by smtp32.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5FA1A56F7; Sat, 11 Mar 2017 16:40:34 -0500 (EST)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.61] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sat, 11 Mar 2017 16:40:35 -0500
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CAOW+2dseq8AmLKXFGUaiss8ahpkY1ZzYUD_KdirFE1rskfvqjw@mail.gmail.com>
Date: Sat, 11 Mar 2017 14:40:33 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <51B1CC11-ABD7-4600-8962-D62715E856F2@iii.ca>
References: <CAOW+2dseq8AmLKXFGUaiss8ahpkY1ZzYUD_KdirFE1rskfvqjw@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/3vQebpgDIXjKtag5g5XWWjYgh3M>
Cc: Flemming Andreasen <fandreas@cisco.com>, Harald Alvestrand <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 21:40:39 -0000

Seem like this question is way out of scope for MMUSIC.  This is about some policy question at the application layer. Cleary the MMUSIC specs support things that play unverified media as well as applications that would not want to play it. 


> On Mar 9, 2017, at 1:10 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> 
> In the W3C WEBRTC WG, an issue has been submitted relating to playout of unverified media:
> https://github.com/w3c/webrtc-pc/issues/849
> 
> It has been suggested that if the browser is configured to do so, that playout be allowed for a limited period (e.g. 5 seconds) prior to fingerprint verification:
> https://github.com/w3c/webrtc-pc/pull/1026
> 
> Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the following text, carried over from RFC 4572:
> 
>    Note that when the offer/answer model is being used, it is possible
>    for a media connection to outrace the answer back to the offerer.
>    Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
>    role, it MUST (as specified in RFC 4145 [7]) begin listening for an
>    incoming connection as soon as it sends its offer.  However, it MUST
>    NOT assume that the data transmitted over the TLS connection is valid
>    until it has received a matching fingerprint in an SDP answer.  If
>    the fingerprint, once it arrives, does not match the client's
>    certificate, the server endpoint MUST terminate the media connection
>    with a bad_certificate error, as stated in the previous paragraph.
> 
> Given the outstanding issue relating to handling of unverified media, the Chairs of the W3C WEBRTC WG would like to request clarification from the IETF MMUSIC WG as to the meaning of the "MUST NOT" in the above paragraph. In particular, what is it permitted for an implementation to do with received data and media prior to verification? For example:
> 
>      1. May data received over the data channel be provided to the application prior to verification?
>          a. If the answer to the above is "no", may unverified received data be delivered by the DTLS transport to SCTP, which may buffer it?
>      2. May received media be played out prior to verification?
> 
> Bernard Aboba
> On behalf of the W3C WEBRTC WG
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

v2.23.0 | Report a Bug | By Email