Re: [ppsp] Kathleen Moriarty's No Objection on draft-ietf-ppsp-base-tracker-protocol-11: (with COMMENT)

"Huangyihong (Rachel)" <> Wed, 16 December 2015 07:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 03B4A1A8825; Tue, 15 Dec 2015 23:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UHgBYl4A7vI4; Tue, 15 Dec 2015 23:12:29 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2489C1A01D6; Tue, 15 Dec 2015 23:12:28 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id CBQ60066; Wed, 16 Dec 2015 07:12:26 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 16 Dec 2015 07:12:25 +0000
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Wed, 16 Dec 2015 15:12:21 +0800
From: "Huangyihong (Rachel)" <>
To: Kathleen Moriarty <>, The IESG <>
Thread-Topic: [ppsp] Kathleen Moriarty's No Objection on draft-ietf-ppsp-base-tracker-protocol-11: (with COMMENT)
Thread-Index: AQHRNvAAUVhaZeA6P0mZ5gruM113FJ7NLeUw
Date: Wed, 16 Dec 2015 07:12:21 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0205.56710EDA.019C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4fbb603b2ffcf20d96361a10ed70df1c
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [ppsp] Kathleen Moriarty's No Objection on draft-ietf-ppsp-base-tracker-protocol-11: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussing to draw up peer to peer streaming protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Dec 2015 07:12:32 -0000

Hi Kathleen,

Thank you for all the valuable comments. Please see my replies inline.


> -----Original Message-----
> From: ppsp [] On Behalf Of Kathleen Moriarty
> Sent: Tuesday, December 15, 2015 10:30 AM
> To: The IESG
> Cc:;;
> Subject: [ppsp] Kathleen Moriarty's No Objection on
> draft-ietf-ppsp-base-tracker-protocol-11: (with COMMENT)
> 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
> 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.

[Rachel]: Will referring to [RFC5590] be better?

> 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.

[Rachel]: Yes. I propose following changes for the last paragraph of 6.1:

   OAuth 2.0 Authorization [RFC6749] SHOULD be also considered when
   digest authentication and HTTPS client certificates are required.
   When peer (Client) authentication is desired at the tracker, HTTP Digest Authentication [RFC7616] MUST be supported.

> 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 mailing list