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

Hi Kathleen,

I'll update it according to your suggestion. Thank you very much.

BR,
Rachel

> -----Original Message-----
> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
> Sent: Wednesday, December 16, 2015 9:37 PM
> To: Huangyihong (Rachel)
> Cc: The IESG; ppsp-chairs@ietf.org; ppsp@ietf.org;
> draft-ietf-ppsp-base-tracker-protocol@ietf.org
> Subject: Re: [ppsp] Kathleen Moriarty's No Objection on
> draft-ietf-ppsp-base-tracker-protocol-11: (with COMMENT)
> 
> Hi Rachael,
> 
> On Wed, Dec 16, 2015 at 2:12 AM, Huangyihong (Rachel)
> <rachel.huang@huawei.com> wrote:
> > Hi Kathleen,
> >
> > Thank you for all the valuable comments. Please see my replies inline.
> >
> > BR,
> > Rachel
> >
> >
> >> -----Original Message-----
> >> From: ppsp [mailto:ppsp-bounces@ietf.org] On Behalf Of Kathleen
> >> Moriarty
> >> Sent: Tuesday, December 15, 2015 10:30 AM
> >> To: The IESG
> >> 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)
> >>
> >> 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-protoco
> >> l/
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> -
> >> 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.
> >
> > [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:
> >
> > OLD
> > "
> >    OAuth 2.0 Authorization [RFC6749] SHOULD be also considered when
> >    digest authentication and HTTPS client certificates are required.
> > "
> > NEW
> > "
> >    When peer (Client) authentication is desired at the tracker, HTTP Digest
> Authentication [RFC7616] MUST be supported.
> > "
> 
> I think what you had is better as it allowed for certificate based authentication
> as well.  HTTP Digest has it's problems, which are cited in RFC7616.  A MUST
> for that isn't a good idea.  Just include the reference for RFC7616 with the
> older text.
> 
> Thank you,
> Kathleen
> 
> >
> >>
> >> 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
> >> ppsp@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ppsp
> 
> 
> 
> --
> 
> Best regards,
> Kathleen