Last Call Review of draft-nottingham-rfc5988bis-05
review-nottingham-rfc5988bis-05-secdir-lc-dekok-2017-05-26-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-nottingham-rfc5988bis-05-secdir-lc-dekok-2017-05-26

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. 

This document describes a model for indicating relationship between resources on the web.  It largely describes concepts, with some "on the wire" specification.

This document is Ready with NITs

Section 2 says:

   ... the relative ordering of links in any
   particular serialisation, or between serialisations (e.g., the Link
   header field and in-content links) is not specified or significant in
   this specification; applications that wish to consider ordering
   significant can do so.

  I'm not sure about the impact of the last statement in that sentence.  If ordering is not significant, why would applications consider it to be significant?  What does that mean to the application, and how does that affect this standard?


Section 2 says:

  Finally, links are consumed by _link applications_.

NIT: I'm not sure what "consumed" means here. Perhaps "interpreted" would be better?


Section 2.1.1 says:

 Registered relation type names MUST conform to the reg-rel-type rule
   (see Section 3.3), and MUST be compared character-by-character in a
   case-insensitive fashion.  

Question: are there any restrictions on the encodings of the strings?  I.e. are they ASCII?  Or UTF-8?

  Having spent some time trying to to i18n in historical protocols, I'm wary of statements which require case-insensitive string matching with no further qualification.

  Similar comments apply to Section 2.1.2.


Section 2.1.1 says:

   ... This practice is NOT RECOMMENDED,
   because the resulting strings will not be considered equivalent to
   the registered relation types by other processors.

NIT: this is the only use of "processors" I can find in the document.  I suggest replacing it with a term used by the rest of the document.


Section 2.1.1.1 says:

   Registration requests consist of at least the following information:

   o  *Relation Name*: The name of the relation type

Question: is this an English name?  The "Description" field states that it is a "shot English description"

  Should the name generally be lowercase?  Uppercase?  Mixed case?

  If the name does not follow existing practices, can the Expert Review suggest changes?

  And for the string comparisons, is this ASCII?  UTF-8?  Some guidance would be appreciated.


Section 2.1.1.2 says:

   The goal of the registry is to reflect common use of links on the
   Internet.  Therefore, the Expert(s) SHOULD be strongly biased towards
   approving registrations, unless they are abusive, frivolous, not
   likely to be used on the Internet, or actively harmful to the
   Internet and/or the Web (not merely aesthetically displeasing, or
   architecturally dubious). 

Question: how are these determinations to be made?  Is there any guidance?

  How can a "Relation name" or "reference" be "abusive", or "actively harmful" ?


Section 5 says:

   The content of the Link header field is not secure, private or
   integrity-guaranteed, and due caution should be exercised when using
   it.  Use of Transport Layer Security (TLS) with HTTP ([RFC2818] and
   [RFC2817]) is currently the only end-to-end way to provide such
   protection.

Question: Is there guidance on what other applications should do with the links?

     Link applications ought to consider the attack vectors opened by
   automatically following, trusting, or otherwise using links gathered
   from HTTP headers.  In particular, Link header fields that use the
   "anchor" parameter to associate a link's context with another
   resource are to be treated with due caution.

Question: what is "due caution"?

  I'd also suggest that *parsing* links is a hard problem, as parsing is (in general) a source of many security issues.

  For examples, see: http://blog.checkpoint.com/2017/05/23/hacked-in-translation/

  Where malicious subtitles can result in video players being compromised.

   The Link header field makes extensive use of IRIs and URIs.  See
   [RFC3987] for security considerations relating to IRIs.  See
   [RFC3986] for security considerations relating to URIs.  See
   [RFC7230] for security considerations relating to HTTP headers.

NIT: I suggest referencing the "Security Considerations" sections directly, instead of just referring to the entire document.