Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT)
Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> Thu, 06 August 2015 04:56 UTC
Return-Path: <muthu.arul@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B04B1B3933; Wed, 5 Aug 2015 21:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 cTY3wY56s6Zc; Wed, 5 Aug 2015 21:56:44 -0700 (PDT)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (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 34C961B3934; Wed, 5 Aug 2015 21:56:44 -0700 (PDT)
Received: by labow3 with SMTP id ow3so41842700lab.1; Wed, 05 Aug 2015 21:56:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6Z3axOxTBLIKq44svPmQNSP5L/NmMxmNM/Ae7R2sDf4=; b=TEf5b1FqQEJtoz/KAemyxYYTLZ5gPWKdGhCDhdRnNKiDO4I+M915zwzqncgW7VFexs krRiHM2EV8lg2Qa6vZofJ6DTvG6o8TH0wiGIKz+1dSHMvCaXN8Whc+YCikdf3CFljATm KbxmfDDI2Zgu4WkPZ0Ka1AT2xQAfIAMxnQ+zcJta7vT1nmVRQGrEFdgQCphMKwu0NFkx 0CskPvYt0O+KZMPhOWzUFLfWuJU9WlAWWoMxf+KHL064lo/NOFpxBrk3MA90+NUFrPHG J770XDpUflCsVu4U5tPkewWBnCeZjzVi9MGLFrjffAIsIefXW2OT2++BlSTwV470MGVD jFoQ==
MIME-Version: 1.0
X-Received: by 10.112.120.134 with SMTP id lc6mr12994287lbb.86.1438837002721; Wed, 05 Aug 2015 21:56:42 -0700 (PDT)
Received: by 10.25.141.213 with HTTP; Wed, 5 Aug 2015 21:56:42 -0700 (PDT)
In-Reply-To: <20150805223837.26225.49192.idtracker@ietfa.amsl.com>
References: <20150805223837.26225.49192.idtracker@ietfa.amsl.com>
Date: Thu, 06 Aug 2015 10:26:42 +0530
Message-ID: <CAKz0y8w7hQWD=dPOwa79CprkbvL5SV7p64xpjLo4zTvaYXAw6Q@mail.gmail.com>
From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="047d7beb9f0c6fe155051c9d58a1"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/8VYyRO7U-j4CfdA1SlErWjUO5ZM>
Cc: draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org, "rtcweb@ietf.org" <rtcweb@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org
Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2015 04:56:51 -0000
Hi Stephen, On Thu, Aug 6, 2015 at 4:08 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-rtcweb-stun-consent-freshness-15: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > > Apologies that these discuss points are maybe asking > fairly fundamental questions. That could be that this > is really the first of the new security things required > by rtcweb to get to the IESG. Or maybe I'm misreading > stuff here, if so, sorry;-) > > (1) Why call this "consent?" That term is (ab)used in > many ways on the web, and adding another variation > without a definition that distinguishes this from "click > ok to my 200 page anti-privacy policy" or "remember that > example.com is allowed use my camera/mic" seems like a > terrible idea. I also don't see how this can ever be > something to which a normal person can "consent" (i.e. > consciously agree while fully understanding) so the term > is IMO very misleading, and will I fear be used to > mislead further. (See also some of the comments below - > I do not think we ought be as fast and loose with this > aleady terribly badly used term.) To summarise: I'd love > if you did s/consent/anything-else/g but if not, please > define consent here in a way that clearly and > unambiguously distinguishes this usage from other abuses > of the term. > The document already has a clear and unambiguous definition of the term, IMHO: Consent: The mechanism of obtaining permission from the remote endpoint to send non-ICE traffic to a remote transport address. Consent is obtained using ICE. Is that definition lacking something? I think finding an alter term would be as hard as finding an alternate term for 'attack' as used in several RFCs [attack being (ab)used in many contexts, including in heart attack ;)] > > (2) WebRTC does not require STUN or TURN servers for > some calls, even if it does for many. Why is it ok to > require such a server be present in all calls (which I > think this means) espcially when that means exposing > additional meta-data (calling parties in a case where > the servers weren't needed and call duration in all > cases) to those servers when that is not always > necessary? > That looks a misunderstanding. Consent freshness doesn't require such server's to be present. Please point out to the text leading to the misunderstanding. > > (3) (end of p5) You have a MUST NOT here that is > depenedent on current browser implementations. Why is > that an IETF thing and not a W3C thing? But more > interestingly, can one securely use this protocol > without the kind of JS vs. browser sandboxing etc that's > needed in the web? Yes, the mechanism has the same security properties within and outside the WebRTC sandboxing. > If the answer is "no" then don't you > need to say that this protocol can only safely be used > for such implementations? (In section 2, which almost > but not quite says that.) > Section 2 doesn't say that. It only says WebRTC is the primary use case for the mechanism at the moment and future use cases based on similar sandboxing models can make use of it. > > (4) Cleared. > > (5) Cleared. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > (Was discuss point#4) > "Section 8: Where are these 96 bits defined? I think > this "requires..." statement needs a precise reference > to the place in some ICE/TURN/STUN RFC where it's > defined. (And I forget where that is, sorry:-) This > should be an easy fix." > Alissa gave me the reference [1] sothat's grand. It > might be an idea to make that clearer if it wasn't > just me missing it as I read, which is very possible;-) > > [1] https://tools.ietf.org/html/rfc5389#section-6 > > - abstract: why is only sending "media" mentioned here? > What about data channels? And the body of the document > in fact says this all applies to any non-ICE data and > not only media. > Agree, that should be "traffic". > > - intro: "initial consent to send by performing STUN" I > do not find the word consent in either rfc5245 or 3489, > but perhaps it is used somewhere else. Where? And with > what meaning? > Consent is a new usage of STUN and is described in draft-ietf-rtcweb-security-arch, draft-ietf-rtcweb-security and in this document. > > - section 4, 2nd last para - I think the conclusion is > bogus. An implementation knows when the keying it's > using can not involve >1 (nominally operating) party. > That paragraph is here: When Secure Real-time Transport Protocol (SRTP) is used, the following considerations are applicable. SRTP is encrypted and authenticated with symmetric keys; that is, both sender and receiver know the keys. With two party sessions, receipt of an authenticated packet from the single remote party is a strong assurance the packet came from that party. However, when a session involves more than two parties, all of whom know each other's keys, any of those parties could have sent (or spoofed) the packet. Such shared key distributions are possible with some MIKEY [RFC3830] modes, Security Descriptions [RFC4568], and EKT [I-D.ietf-avtcore-srtp-ekt]. Thus, in such shared keying distributions, receipt of an authenticated SRTP packet is not sufficient to verify consent. I'll defer it to someone who has more knowledge that me on shared key distribution.. > > - 5.1, 3rd para: "Explicit consent to send is > obtained..." is misleading. That is not a concept that > an implementation of STUN will embody. > As said earlier, consent is a new STUN usage. How would the following? An endpoint that implements this specification obtains and maintains consent to send by sending STUN binding request... > > - 5.1, What is the "Note" about TCP for? Why is this > needed? > It is needed because WebRTC data traffic sent over TCP could get converted to UDP by TURN servers. It is somewhat similar to why we need application layer security when traffic is sent over IPSec. The later may not be end-to-end. Muthu
- [rtcweb] Stephen Farrell's Discuss on draft-ietf-… Stephen Farrell
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Christer Holmberg
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Eric Rescorla
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Stephen Farrell
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Eric Rescorla
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Stephen Farrell
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Stephen Farrell
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Eric Rescorla
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Eric Rescorla
- [rtcweb] TURN permissions for private ips (was: R… Philipp Hancke
- Re: [rtcweb] [tram] TURN permissions for private … Simon Perreault
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Alissa Cooper
- Re: [rtcweb] [tram] TURN permissions for private … Justin Uberti
- Re: [rtcweb] [tram] TURN permissions for private … Simon Perreault
- Re: [rtcweb] [tram] TURN permissions for private … Eric Rescorla
- Re: [rtcweb] [tram] TURN permissions for private … Philipp Hancke
- [rtcweb] Stephen Farrell's Discuss on draft-ietf-… Stephen Farrell
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Stephen Farrell
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Muthu Arul Mozhi Perumal
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Christer Holmberg
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Christer Holmberg
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Xavier Marjou
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Alissa Cooper
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Stephen Farrell
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Stephen Farrell
- Re: [rtcweb] [tram] TURN permissions for private … Emil Ivov
- Re: [rtcweb] [tram] TURN permissions for private … Jonathan Lennox
- Re: [rtcweb] [tram] TURN permissions for private … Justin Uberti
- Re: [rtcweb] [tram] TURN permissions for private … Martin Thomson
- Re: [rtcweb] [tram] TURN permissions for private … Jonathan Lennox
- Re: [rtcweb] [tram] TURN permissions for private … Roman Shpount
- Re: [rtcweb] [tram] TURN permissions for private … Martin Thomson
- Re: [rtcweb] [tram] TURN permissions for private … Justin Uberti
- Re: [rtcweb] [tram] TURN permissions for private … Emil Ivov
- Re: [rtcweb] [tram] TURN permissions for private … Justin Uberti
- Re: [rtcweb] [tram] TURN permissions for private … Emil Ivov
- Re: [rtcweb] [tram] TURN permissions for private … Pal Martinsen (palmarti)
- Re: [rtcweb] [tram] TURN permissions for private … Emil Ivov
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Martin Thomson
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Muthu Arul Mozhi Perumal
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Ram Mohan R (rmohanr)
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Ram Mohan R (rmohanr)
- Re: [rtcweb] Stephen Farrell's Discuss on draft-i… Stephen Farrell
- Re: [rtcweb] [tram] TURN permissions for private … Justin Uberti
- Re: [rtcweb] [tram] TURN permissions for private … Cullen Jennings
- Re: [rtcweb] [tram] TURN permissions for private … Justin Uberti