Re: [MMUSIC] Handling of unverified data and media

Roman Shpount <roman@telurix.com> Fri, 10 March 2017 22:47 UTC

Return-Path: <roman@telurix.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 5365912940F for <mmusic@ietfa.amsl.com>; Fri, 10 Mar 2017 14:47:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 VoOYPTAWuMvk for <mmusic@ietfa.amsl.com>; Fri, 10 Mar 2017 14:47:46 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 C66DE1293E8 for <mmusic@ietf.org>; Fri, 10 Mar 2017 14:47:46 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id j5so46871298pfb.2 for <mmusic@ietf.org>; Fri, 10 Mar 2017 14:47:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fHFZLs28GhD6VqUiWAy91IPsIZ3An9foSsNMrjmrQ/Y=; b=QlAQnUy/n0162eQb0C4XqrBIYiAU167q0Wxpl8TXpUpIJbSZvRiwWY7jCj19f4BweX M5KJEnYgfhJWf+MynyJyeduzySahAGD1D7PLHQi3giTeiZ5Ve6+YxhzjQ10tEnTbyvhI bU4NK6fPtn9xWhg5/PKO/YYq5/GdXkufWhGiuUTzxvC8SJdynJO3jkhmf11OKTYA/dxi FfLz+NPaS1qQTdG8ohSo3UwkYK3fNLYc95Vpo6WFOJRInSfv8Y7wSndENSC5RNkT+VdW tMYk/kn0bCcWwUPPIBi2ZdXnZ1rdHkQMT4IXiMIbnGZ5k3nJeG3ldZbpALmhx8AnQ87t rX+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fHFZLs28GhD6VqUiWAy91IPsIZ3An9foSsNMrjmrQ/Y=; b=YMcXEtl+AA+makShe8DMRuDAHM3vo7d8Tu2lOzAEuIAhrrF6/OCZIrbFImYVWyQCud suA+AE8dUCQ7xX2hZEKQzrzNxkT1m38KvE1ml+UUtosS1x2ag8Po9smTeOokY3PYihyh aVoVQGOivkrbMkZyMmnm5qivEcJRemXtqjyPjUIy11n1zR610WMTpLSrQYFJS2ahttPR 55u9xhPIye9r2Q9PRRCxRrAaaAjFd/8mLmWnQ99ETNxRInoEnnhLxgHJyzmnybg3d7D1 nf+BJp2ISvwccQ3GTqB2DZ+n+JArdMvnGbfYWqrYnYhljE6dDx0yek7BDkk9BVzF25t9 VEcA==
X-Gm-Message-State: AMke39ls2JdM9rr46J0KJ1+FPfxfyysCy1vXZtcOf62A5jZrkIOtXpzGeMHqQjIYTFh4SA==
X-Received: by 10.84.217.215 with SMTP id d23mr29191233plj.33.1489186066267; Fri, 10 Mar 2017 14:47:46 -0800 (PST)
Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com. [209.85.192.178]) by smtp.gmail.com with ESMTPSA id d66sm20472552pfe.90.2017.03.10.14.47.45 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Mar 2017 14:47:45 -0800 (PST)
Received: by mail-pf0-f178.google.com with SMTP id j5so46871060pfb.2 for <mmusic@ietf.org>; Fri, 10 Mar 2017 14:47:45 -0800 (PST)
X-Received: by 10.99.138.202 with SMTP id y193mr23012617pgd.60.1489186064622; Fri, 10 Mar 2017 14:47:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.161.144 with HTTP; Fri, 10 Mar 2017 14:47:44 -0800 (PST)
In-Reply-To: <CABkgnnUc-XsYivUzSs6W4it_Krykr-reJMDJXqKf5FvGw_NBPg@mail.gmail.com>
References: <CAOW+2dseq8AmLKXFGUaiss8ahpkY1ZzYUD_KdirFE1rskfvqjw@mail.gmail.com> <CABkgnnUc-XsYivUzSs6W4it_Krykr-reJMDJXqKf5FvGw_NBPg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Fri, 10 Mar 2017 17:47:44 -0500
X-Gmail-Original-Message-ID: <CAD5OKxvXTsTPaKFNdwS6tPBTAksD=jgiAFGuGMgbepOtBoFT+Q@mail.gmail.com>
Message-ID: <CAD5OKxvXTsTPaKFNdwS6tPBTAksD=jgiAFGuGMgbepOtBoFT+Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c03aefa62f5ae054a6826af
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/xuzihlObAhh23LU2on1jFlGS5xo>
Cc: Flemming Andreasen <fandreas@cisco.com>, "hta@google.com" <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: Fri, 10 Mar 2017 22:47:48 -0000

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>
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> 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
> >
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>