Re: [MMUSIC] Handling of unverified data and media

Martin Thomson <> Fri, 10 March 2017 02:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55A8A1294E0 for <>; Thu, 9 Mar 2017 18:42:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N0aukYRnvcYP for <>; Thu, 9 Mar 2017 18:42:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6330D1294D6 for <>; Thu, 9 Mar 2017 18:42:45 -0800 (PST)
Received: by with SMTP id y76so149789261qkb.0 for <>; Thu, 09 Mar 2017 18:42:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ks4AnI2sgYPEYKN4RKK2ZGWxi8B7ooE0C/Ktu6Col1s=; b=NdJfLwU1tLv0y5jiHmsrcyDRJ794cU7evngdQqHcfugMxwUKRLIDkDoNADU2op8d5A iMMru1fB/DsEUVEEhDh/J8m5e/nG64+fzmjV/d85TZBYKq0mg8wujqagudwOQfl0RGJ/ Fpc51G67Wfj1cfon3rKqEWqEAWqfyheMk20aB0SJ48PSTVhp6ArFeJgbuvvRtUSbshIq t+wvVVn3BGTm+taZRyzpx8QC7JnrOwD3HxUP2JEmY8sIy4emmguVjWSKDLjffsAQJR41 a0rznHHEs6o/742MDnjVDcWIghim2ELUWFEXGBNxCOwUiq5xyPhXQZatcNiGRlgFcxjk zb9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ks4AnI2sgYPEYKN4RKK2ZGWxi8B7ooE0C/Ktu6Col1s=; b=nYGhCZASITATEOiwLJ4IkcysoilgivoI2Ga7FwrsfyQCPavmy5R4YZTZG5xqasAqFC HYGl5V7Zc+VqkWL7YFteEbPzThI4cdXzv9RDZRaP+CMvgX9fi+dR+yMWP8f6G+pu3JxA 0nc8ivDOidovD07FLt5APMCTkmPzjHPMiRs8KW1uOCq11oTEhKe9fZdmZ8n+ctNziCsX N212dpkEZ6DRt+tnQ2SoLGPHWwFFCbteQ/1xLAGUfb8Gm9snAUAxy11yoDbrMM6nkkKd zSIc+Z9M/kt8FfJFCdTXzZZ2xJqmqbVmp1Zi3ry2kZiAI1/qB9O0kvmSTaRu/9Hci1CZ te8g==
X-Gm-Message-State: AFeK/H2KPF0ca2fi/espobHTOSfUSrZEH3zcy8RLYbp5VAdg5x0XlbtF4p+tqckz/iYAxREG/s17/pNAbZsGzw==
X-Received: by with SMTP id z7mr16679291qkd.316.1489103881041; Thu, 09 Mar 2017 15:58:01 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 9 Mar 2017 15:58:00 -0800 (PST)
In-Reply-To: <>
References: <>
From: Martin Thomson <>
Date: Fri, 10 Mar 2017 10:58:00 +1100
Message-ID: <>
To: Bernard Aboba <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: Flemming Andreasen <>, "" <>, mmusic WG <>
Subject: Re: [MMUSIC] Handling of unverified data and media
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Mar 2017 02:42:47 -0000

I think that the data channel question is easy, anything other than a
"no" is not acceptable.  Data in that form enters the security
boundary for an origin and it doesn't make any sense to risk attack
there.  (It's also likely unnecessary, if a half a round trip of
signaling is slower than 5 round trips on the media path, then
something is messed up.)

I'm in two minds about the media part. For media, you could also
reasonably make the same origin-purity argument.  I'm inclined to say
that.  But we CAN isolate media from the origin (and we definitely
should if we allow this).

So, the media that arrives had to comply with your offer.  The DTLS
handshake also has to complete, which tells the receiver whether the
media needs to be confidential or not (at which point you can disable
this feature).

It's also possible that a receiver can require that an ICE
connectivity check was made (though this is inbound only, and I'm
unclear on whether having received an inbound check would normally
prevent the receiver from accepting a packet).

All told, that's a lot of information about the negotiated session for
an attacker to have.  The odds of this being an attack would *seem* to
be low.

On the other hand, we don't assume confidentiality of signaling; the
security model assumes that all this information is effectively public
and the protection we have against attack is the certificate
fingerprint.  This would remove that protection, albeit for a short

I have an extra question: does anyone plan to implement this?  It's
non-trivial.  I think that I know what I'd need to do in Firefox and
it would be quite disruptive.  Before committing to do that work
(which I will leave to others closer to this to decide), I'd probably
want more information on the actual advantage that it provides.

On 10 March 2017 at 07:10, Bernard Aboba <> wrote:
> In the W3C WEBRTC WG, an issue has been submitted relating to playout of
> unverified media:
> 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:
> 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