[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:


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!