Skip to main content

Last Call Review of draft-nottingham-rfc5988bis-05

Request Review of draft-nottingham-rfc5988bis
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-05-26
Requested 2017-04-28
Authors Mark Nottingham
I-D last updated 2017-05-26
Completed reviews Genart Last Call review of -05 by Stewart Bryant (diff)
Opsdir Last Call review of -05 by Carlos M. Martínez (diff)
Secdir Last Call review of -05 by Alan DeKok (diff)
Genart Telechat review of -07 by Stewart Bryant (diff)
Assignment Reviewer Alan DeKok
State Completed
Request Last Call review on draft-nottingham-rfc5988bis by Security Area Directorate Assigned
Reviewed revision 05 (document currently at 08)
Result Has nits
Completed 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

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

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

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

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

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

Section 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

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:

  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.