Re: [MMUSIC] Handling of unverified data and media

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 13 March 2017 21:45 UTC

Return-Path: <christer.holmberg@ericsson.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 B07CA127058 for <mmusic@ietfa.amsl.com>; Mon, 13 Mar 2017 14:45:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 beuzWlBJreDb for <mmusic@ietfa.amsl.com>; Mon, 13 Mar 2017 14:45:45 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 249C2129477 for <mmusic@ietf.org>; Mon, 13 Mar 2017 14:45:44 -0700 (PDT)
X-AuditID: c1b4fb25-e49bd98000004cad-3f-58c71307d235
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 36.83.19629.70317C85; Mon, 13 Mar 2017 22:45:43 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0319.002; Mon, 13 Mar 2017 22:45:17 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Jonathan Lennox <jonathan@vidyo.com>
Thread-Topic: [MMUSIC] Handling of unverified data and media
Thread-Index: AQHSmfBaeuX9ya5EIEOzUwYnxet2SaGOsIkAgAABT4CAAA4wAIAA+MdggAO42wD//9++UA==
Date: Mon, 13 Mar 2017 21:44:55 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se>
References: <CAOW+2dseq8AmLKXFGUaiss8ahpkY1ZzYUD_KdirFE1rskfvqjw@mail.gmail.com> <CABkgnnUc-XsYivUzSs6W4it_Krykr-reJMDJXqKf5FvGw_NBPg@mail.gmail.com> <CAD5OKxvXTsTPaKFNdwS6tPBTAksD=jgiAFGuGMgbepOtBoFT+Q@mail.gmail.com> <CABcZeBO9MP0fqg=ubpgU8+3L9koB5grCyp-O8hS9Pis942-rhA@mail.gmail.com> <CAOW+2due+uNyWn-3GQnpXrR-L55XVZSXXRmC0E9-5BSGKynUYA@mail.gmail.com> <CABcZeBPr4OjUBSUdS3wWmUuRJh7XmgxfVaY1F15mjMAqjbTZRg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com>
In-Reply-To: <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB0B034ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUyM2K7li678PEIg6XflCw27PvPbLHi9Tl2 i/cXdC1O3DjNbLF/8Xlmi6nLH7M4sHlM+b2R1WPnrLvsHgs2lXosWfKTyWPy4zZmj7Znd9gD 2KK4bFJSczLLUov07RK4Mo79usBesOU6U8XvZ1kNjDvOMXUxcnJICJhITP38gBXEFhJYxyjx fZdbFyMXkL2YUWJazx3mLkYODjYBC4nuf9ogNSICGhIXn31gA6lhFtjCKNGwpIkJpEZYwFri Sj8riCkiYCOx8lctRHmYxKo5R1hAbBYBVYn2lXPYQWxeAV+J97seM0KsWsUicaf3CNg9nAK2 Ei9m7mMGsRkFxCS+n1oDFmcWEJe49WQ+1M0CEkv2nGeGsEUlXj7+xwphK0ms2H6JEaI+X+Lt oTdMEMsEJU7OfMIygVFkFpJRs5CUzUJSNgvoBWYBTYn1u/QhShQlpnQ/ZIewNSRa58xlRxZf wMi+ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwQg9u+a26g/HyG8dDjAIcjEo8vB82H4sQ Yk0sK67MPcQowcGsJMKrsxEoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNds5f1wIYH0xJLU7NTU gtQimCwTB6dUA6PaJN/e1leLVzHtsuI03ym1asr2nB+iG7YpXGINj5v2sSQ11fjn8nc153Q2 VLSu8Z4rXa3Qvfs7u+e7D7uudVRFxJ0UcN52MjBtEfNbe4OZhwsdozRVtwr/23uYVfTmRVlG +8hXkm/9D1x6e295JkPT7S2FU0pcLgiJixRwezjIHLWOu6pYO02JpTgj0VCLuag4EQCBJJCA zAIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/4eAK8tW82DDimzZEYTXvp0Eo-a0>
Cc: Flemming Andreasen <fandreas@cisco.com>, Harald Alvestrand <hta@google.com>, mmusic <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: Mon, 13 Mar 2017 21:45:48 -0000

Hi,

If the answerer is in such a “hurry” to start sending media, one would think it also makes sure the answer is sent as early as possible, so that media can flow in both directions.

My question is: is this something that’s causing problems in real deployments, and requires a change in the standard? To me it seems like something that is very unlikely to occur, or at least like something that can easily be avoided by implementation means…

Regards,

Christer

From: Jonathan Lennox [mailto:jonathan@vidyo.com]
Sent: 13 March 2017 20:37
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Eric Rescorla <ekr@rtfm.com>om>; Bernard Aboba <bernard.aboba@gmail.com>om>; Flemming Andreasen <fandreas@cisco.com>om>; Harald Alvestrand <hta@google.com>om>; mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Handling of unverified data and media


On Mar 11, 2017, at 9:52 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:

Hi,

Is this a theoretical issue?

At least if you use ICE, you are going to receive the answer before you receive any media, as you are going to do the connectivity checks etc.

No, even with ICE it’s possible for media or the DTLS handshake to outrace the answer.

This is because ICE offering endpoints respond to connectivity checks before they receive an answer.  When the answerer receives this successful connectivity check response, it puts the relevant pair in the Valid list, and then (if it has the active role, as recommended) can legitimately initiate DTLS on this pair.

If two ICE endpoints have a short RTT and clear connectivity between them, but a long RTT to their signaling server, this can happen quite easily.


Also, in reality some implementations will not accept content before the answer arrives – no matter if DTLS is used or not – so the best thing is to, once the answer has been sent, just wait for a while before sending any content.

Fortunately, DTLS has retransmissions, so this shouldn’t cause failure, just a brief setup delay.



Regards,

Christer

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: 11 March 2017 02:57
To: Bernard Aboba <bernard.aboba@gmail.com<mailto:bernard.aboba@gmail.com>>
Cc: Flemming Andreasen <fandreas@cisco.com<mailto:fandreas@cisco.com>>; hta@google.com<mailto:hta@google.com>; mmusic WG <mmusic@ietf.org<mailto:mmusic@ietf.org>>
Subject: Re: [MMUSIC] Handling of unverified data and media

Sorry, no, I was just talking about what might or might not be safe.... The doc text is
a different question.

-Ekr


On Fri, Mar 10, 2017 at 4:05 PM, Bernard Aboba <bernard.aboba@gmail.com<mailto:bernard.aboba@gmail.com>> wrote:
EKR said:

"I haven't spent too much time on it, but it seems like it ought to be safe to hold
anything you receive prior to getting the fingerprint. It might be better, as MT
suggests, to discard the datachannel data, but I'm not sure why it would be
necessary."

[BA] So you are saying that the MUST NOT allows the browser to buffer data/media but not to pass it to the application (in the case of the data channel) or to play it out?

On Fri, Mar 10, 2017 at 4:01 PM, Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:
I haven't spent too much time on it, but it seems like it ought to be safe to hold
anything you receive prior to getting the fingerprint. It might be better, as MT
suggests, to discard the datachannel data, but I'm not sure why it would be
necessary.

-Ekr

On Fri, Mar 10, 2017 at 2:47 PM, Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>> wrote:
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.

Regards,

_____________
Roman Shpount

On Thu, Mar 9, 2017 at 6:58 PM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
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
duration.

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 <bernard.aboba@gmail.com<mailto: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<mailto:mmusic@ietf.org>
> https://www.ietf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic