[ppsp] Kathleen Moriarty's No Objection on draft-ietf-ppsp-base-tracker-protocol-11: (with COMMENT)
"Kathleen Moriarty" <Kathleen.Moriarty.ietf@gmail.com> Tue, 15 December 2015 02:29 UTC
Return-Path: <Kathleen.Moriarty.ietf@gmail.com>
X-Original-To: ppsp@ietf.org
Delivered-To: ppsp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EAB1ADEB6; Mon, 14 Dec 2015 18:29:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151215022950.16440.50969.idtracker@ietfa.amsl.com>
Date: Mon, 14 Dec 2015 18:29:50 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/ppsp/G09UCZ5mWNQTCAB7DdQnXZqPYOk>
X-Mailman-Approved-At: Mon, 14 Dec 2015 20:20:48 -0800
Cc: ppsp-chairs@ietf.org, ppsp@ietf.org, draft-ietf-ppsp-base-tracker-protocol@ietf.org
Subject: [ppsp] Kathleen Moriarty's No Objection on draft-ietf-ppsp-base-tracker-protocol-11: (with COMMENT)
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ppsp/>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Dec 2015 02:29:50 -0000
Kathleen Moriarty has entered the following ballot position for draft-ietf-ppsp-base-tracker-protocol-11: 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-ppsp-base-tracker-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. Section 5.2.7 Please make mention and reference to security provisions for SNMP and Syslog. RFC5424 is just for syslog, so a pointer for SNMP security considerations should be added in this section as well. They use a boilerplate for the text and add considerations specific to a draft. Benoit - do you have a good reference for them to use? A more generic SNMP draft might not be up-to-date with the latest boilerplate text. If that's the case, the recent changes are small and could be stated with a pointer to an RFC with the older boilerplate text. - Thanks for adding an SNMP reference. I would think there is a better, more recent one that could be used. Moving to a comment for your AD to help you with and not hold up on this one. 2. Are there any considerations for the statistics collected, can they be used in a malicious way? I would think so and that this would be an important security consideration. Mentioning possible issues would be helpful to the reader. - Thanks for adding in text about this one! 3. Section 6 Reference to RFC2616 isn't enough for the security considerations of HTTP since that's a really old RFC. If you want authentication options, you could point to the HTTPAuth documents, which include updated versions of HTTP basic (RFC7616) and digest (RFC7617). While there are still lots of security issues with these options, the RFCs spell out what the actual considerations are, which are helpful to the reader. This raises the need for TLS 1.2 as well to provide session protection for the session (passive and active attacks) as well as for the authentication used. You mention HTTPAuth's digest in 6.1, but there's no reference. This is a little better, so I am moving this to a comment from discuss. 4. Section 6.1 Why isn't TLS a must here to protect the session data? If you are relying on OAuth Bearer tokens, they offer no security protection without TLS, so to rely on this, I'd say TLS really should be a MUST. The authentication types to get a bearer token (at least in RFC documentation and in the registry) are all pretty weak and require TLS protection to have any level of security. With the TLS MUST, we are recommending TLS 1.2 as the minimum in drafts. It would be good to see a mention of TLS 1.2 as a minimum recommendation and a reference to the BCP for TLS 1.2 configurations RFC7525 (it even includes cipher suite recommendations). - Thanks for adding in the MUST for TLS and the reference to RFC7525. 5. Privacy I would have expected some discussion on the protection of the 2 ID types and the tracker capabilities and that session encryption (TLS) ought to be used when this is a consideration. Is there a reason this isn't covered? If it's not a concern, I'd like to understand why. -Thanks for adding in a privacy section!
- [ppsp] Kathleen Moriarty's No Objection on draft-… Kathleen Moriarty
- Re: [ppsp] Kathleen Moriarty's No Objection on dr… Huangyihong (Rachel)
- Re: [ppsp] Kathleen Moriarty's No Objection on dr… Huangyihong (Rachel)
- Re: [ppsp] Kathleen Moriarty's No Objection on dr… Kathleen Moriarty