[MMUSIC] Handling of unverified data and media

[Bernard Aboba <[e-mail]>]

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