Re: [ppsp] Kathleen Moriarty's Discuss on draft-ietf-ppsp-base-tracker-protocol-10: (with DISCUSS)

["Huangyihong (Rachel)" <[e-mail]>]

Hi Kathleen,

Thank you so much for the valuable comments and I'm sorry for my late replies. Please see them inline.

BR,
Rachel


> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Thanks for your work on this draft, I have a few things I'd like to discuss that we
> should be able to resolve quickly.  I'll try where possible to offer suggestions,
> but please do let me know if there is a good reason why they don't make sense.
> 
> 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.

[Rachel]: How about referencing to [RFC3411]? 

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

[Rachel]: You're right. How about following change?

OLD

"
   The statistics collected about the operation of PPSP-TP can be used
   for detecting attacks, such as the receipt of malformed messages,
   messages out of order, or messages with invalid timestamps.
"

NEW
"
The statistics collected about the operation of PPSP-TP can be used for detecting attacks, such as the receipt of malformed messages, messages out of order, or messages with invalid timestamps. However, collecting such endpoint properties may also raise some security issues. For example, the statistics collected by the tracker may be disclosed to an unauthorized third party which has some malicious intention. To address such risk, the provider of the tracker should evaluate how much information is revealed and the associated risks. And confidentiality mechanism must be provided by HTTP over TLS to guarantee the confidentiality of PPSP-TP.
"

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

[Rachel]: You're right. Here we mean the security consideration for general HTTP architecture and messaging. So I should point to [RFC7230]? And the authentication is discussed in Section 6.1.

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

[Rachel]: Ok. How about changing the 3rd paragraph from

OLD
"
   A channel-oriented security mechanism should be used in the
   communication between peers and tracker, such as the Transport Layer
   Security (TLS) to provide privacy and data integrity.
" 
To

NEW
"
Transport Layer Security (TLS) [RFC5246] MUST be used in the communication between peers and tracker to provide privacy and data integrity.
"

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

[Rachel]: So for mentioning TLS, we should point to TLS 1.2 [RFC5246], right?  And we can add following words into 3rd paragraph of section 6.1 for mentioning the BCP.

" 
Software engineers developing and service providers deploying the tracker should make themselves familiar with the Best Current Practices (BCP) on configuring HTTP over TLS [RFC7525].
"

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

[Rachel]: It should be considered. I have replied Ben's mail in which privacy consideration in Section 6 is proposed. Please see following

NEW
"
Section 6.5  Privacy for Peers

The PPSP-TP provides mechanisms in which the peers can send message containing IP addresses, ports and other information to the tracker. A tracker or a third party who is able to intercept such messages can store and process the obtained information in order to analyze peers' behaviors and communication patterns. Such analysis can lead to privacy risks. For example, an unauthorized party may snoops on the data transmission from the peer to a tracker in order to introduce some corrupted chunks. 

The PPSP peer protocol [RFC7574] has already included some mechanisms to protect the streamed content, see section 12.3 and 12.4 of [RFC7574]. For PPSP-TP, peer implementations as well as tracker implementations MUST support the "https" URI scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246]. In addition, a peer should be cognizant about potential tracker tracking through queries of peers, e.g., by using HTTP cookies. The PPSP-TP protocol specified in this document does not rely on HTTP cookies. Thus, peers MAY decide not to return cookies received from the tracker, in order to making some additional tracking more difficult.
"

> 
> 
>