[tram] Benoit Claise's No Objection on draft-ietf-tram-stun-origin-05: (with COMMENT)
"Benoit Claise" <bclaise@cisco.com> Tue, 12 May 2015 13:36 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B4F1A870D; Tue, 12 May 2015 06:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3QmhQzFnAC9J; Tue, 12 May 2015 06:36:07 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DA31A86E0; Tue, 12 May 2015 06:36:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.2.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150512133607.26808.51688.idtracker@ietfa.amsl.com>
Date: Tue, 12 May 2015 06:36:07 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/tram/IylCeyDDCpAnQhBSh2_LfMdQsY0>
Cc: tram-chairs@ietf.org, tram@ietf.org, draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, sperreault@jive.com, tjc@ecs.soton.ac.uk, draft-ietf-tram-stun-origin@ietf.org
Subject: [tram] Benoit Claise's No Objection on draft-ietf-tram-stun-origin-05: (with COMMENT)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2015 13:36:09 -0000
Benoit Claise has entered the following ballot position for draft-ietf-tram-stun-origin-05: No Objection 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-tram-stun-origin/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Here is Tim Chown's OPS DIR review, along the same lines as Stephen and Alissa's DISCUSSES. The feedback was sent to the authors on April 22nd, and I have not seen any reply so far. Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I would summarise this document as being Not Ready. My concern with the draft lies with privacy aspects. While the area is not one that I am particularly familiar with, but there would seem to be additional potential exposure through this method, and the language of the draft seems at odds with the language in RFC6454 (Section 7.3). I would therefore urge the AD to review this aspect, and to determine whether the utility of the draft outweighs the privacy concerns, and if it does, that appropriate privacy ‘knobs’ are included for those who are ‘privacy-sensitive’ (in the language of RFC6454). I think the rationale and tradeoffs could be more clearly stated in the document. With recent passive pervasive monitoring threats, the IETF is now supposed to be considering whether given information *needs* to be transmitted in any given protocol. Would I as a user, for example, be able to toggle a setting that would mean my ORIGIN would always be “null”, as per RFC6454 section 7.3? Is the use of ORIGIN *required*, or is it just ‘desirable’? Would my application fail, or not? It appears from Section 1 that its inclusion is ‘useful’, but not required. Section 4 talks of TLS for avoiding eavesdropping of ORIGIN in STUN messages, but the privacy concern is not necessarily only with transmission of the information. I think here paragraph 3 of Section 4 is at odds with RFC6454 Section 7.3 - with this draft saying MAY wrt use of a “null” Origin, and RFC6454 saying MUST for use of “null”. The same applies to the end of the last paragraph in Section 4 as well. The draft should probably use the ‘privacy-senstive’ context terminology of RFC6454, as per Section 7.3, and describe how the user can influence the privacy settings where they which to maximise their privacy. Tim ===================================================== A point of detail, really, if you update the draft. For a web application provider STUN or TURN server, the server will have no idea which web pages or sites are sending binding requests to the service. In conventional applications, the SOFTWARE attribute would provide some identifying information to the service, but that no longer works when the browser is the application. SOFTWARE attribute: a reference to http://tools.ietf.org/html/rfc5389#section-15.10 would be beneficial
- [tram] Benoit Claise's No Objection on draft-ietf… Benoit Claise
- [tram] Benoit Claise's No Objection on draft-ietf… Benoit Claise