[MMUSIC] Handling of unverified data and media
Bernard Aboba <bernard.aboba@gmail.com> Thu, 09 March 2017 20:10 UTC
Return-Path: <bernard.aboba@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 6851C1293E1 for <mmusic@ietfa.amsl.com>; Thu, 9 Mar 2017 12:10:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 u-9Eas8y5rep for <mmusic@ietfa.amsl.com>; Thu, 9 Mar 2017 12:10:22 -0800 (PST)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 ECF59126D74 for <mmusic@ietf.org>; Thu, 9 Mar 2017 12:10:21 -0800 (PST)
Received: by mail-ua0-x22a.google.com with SMTP id u30so94031538uau.0 for <mmusic@ietf.org>; Thu, 09 Mar 2017 12:10:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=WI5/qcRItyoDamML7K/uxDWYNKduLKJtt9b+Pdmd3/k=; b=Zp2TZlEZRD3/sIzIkOITKIdWirQx1bfG9VWvFH3zlHi2vbS5FAZHfTFoLGUk+OMEuC VWb1DqCLL/SHImPZBKiekGfvW4u70xv79JeHPiNGfkUS3oV2AmY41pvMwZCaBQ1bs4pC 87CIQMXbIkW/furgAOvG9otmskFfgtQ0AiMAyffq72+8y6G0EGB3P7RgwmLDHzoU4HM4 6sGcO/aN3KccksHD1wUH/qSajGuDjXqIhIs0P1GrS3oM9H6kyF+P8PxRgRrcGKEFUe1g S1HarW9PvKkWx0QH+uEmz9dRYDxaZItkKvtWFsz25lQryBxCy+Tf4yvn9BTHhkcnhAaY 8yDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=WI5/qcRItyoDamML7K/uxDWYNKduLKJtt9b+Pdmd3/k=; b=WtG79fiOqUQm8QXYoLBtDBFrD7YmmzxgwdCh44mS2wvJswmKz3IpySnfBhOo/crIrB s+MZLLPBnG7kkByqYhWJyg6z+VgpM86QX6fwVCiIuN3JHGOvgkFiTd1OLHa4qoUpArBd CWoB2tgdjAqKlZyOA7l31HwR8rsvOM35BCcqzsP6s2j5Wrbcr8cgowUOKTMzvX+71+0e ji3QoD1u6FgxOdtb65etIth6VDfH09iQ11kmJlOZx7OMiM81kLJEVsN2SwDzrdG40hGv xHYhdVxvMpEENipHkguqKuCcKiJ46Dm4/nEJmCc5GS2pP1/k6ZdnyuonyCIhI+Wv/BFH f+ag==
X-Gm-Message-State: AMke39mqBGArup/Qnn3C1qpTR20LHKcR0aTycQYkm+SCSFDDO0bCVeOeNshD9/BfFO9n98OypEJ6RowP1rw08g==
X-Received: by 10.176.83.142 with SMTP id k14mr6550839uaa.64.1489090220954; Thu, 09 Mar 2017 12:10:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.88.90 with HTTP; Thu, 9 Mar 2017 12:10:00 -0800 (PST)
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Thu, 09 Mar 2017 12:10:00 -0800
Message-ID: <CAOW+2dseq8AmLKXFGUaiss8ahpkY1ZzYUD_KdirFE1rskfvqjw@mail.gmail.com>
To: Bo Burman <bo.burman@ericsson.com>, Flemming Andreasen <fandreas@cisco.com>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="f403045e2274a8a124054a51d568"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/Yp7rGlTchqVU6ruIlfjokqs307g>
Cc: "hta@google.com" <hta@google.com>
Subject: [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: Thu, 09 Mar 2017 20:10:23 -0000
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] Handling of unverified data and media Bernard Aboba
- Re: [MMUSIC] Handling of unverified data and media Martin Thomson
- Re: [MMUSIC] Handling of unverified data and media Roman Shpount
- Re: [MMUSIC] Handling of unverified data and media Eric Rescorla
- Re: [MMUSIC] Handling of unverified data and media Bernard Aboba
- Re: [MMUSIC] Handling of unverified data and media Eric Rescorla
- Re: [MMUSIC] Handling of unverified data and media Christer Holmberg
- Re: [MMUSIC] Handling of unverified data and media Iñaki Baz Castillo
- Re: [MMUSIC] Handling of unverified data and media Christer Holmberg
- Re: [MMUSIC] Handling of unverified data and media Iñaki Baz Castillo
- Re: [MMUSIC] Handling of unverified data and media Christer Holmberg
- Re: [MMUSIC] Handling of unverified data and media Cullen Jennings
- Re: [MMUSIC] Handling of unverified data and media Martin Thomson
- Re: [MMUSIC] Handling of unverified data and media Jonathan Lennox
- Re: [MMUSIC] Handling of unverified data and media Roman Shpount
- Re: [MMUSIC] Handling of unverified data and media Christer Holmberg
- Re: [MMUSIC] Handling of unverified data and media Jonathan Lennox
- Re: [MMUSIC] Handling of unverified data and media Christer Holmberg
- Re: [MMUSIC] Handling of unverified data and media Cullen Jennings
- Re: [MMUSIC] Handling of unverified data and media Peter Thatcher
- Re: [MMUSIC] Handling of unverified data and media Martin Thomson
- Re: [MMUSIC] Handling of unverified data and media Bernard Aboba
- Re: [MMUSIC] Handling of unverified data and media Martin Thomson
- Re: [MMUSIC] Handling of unverified data and media Peter Thatcher
- Re: [MMUSIC] Handling of unverified data and media Roman Shpount
- Re: [MMUSIC] Handling of unverified data and media Cullen Jennings
- Re: [MMUSIC] Handling of unverified data and media Cullen Jennings
- Re: [MMUSIC] Handling of unverified data and media Martin Thomson
- Re: [MMUSIC] Handling of unverified data and media Peter Thatcher
- Re: [MMUSIC] Handling of unverified data and media Roman Shpount
- Re: [MMUSIC] Handling of unverified data and media Peter Thatcher