[secdir] secdir review of draft-ietf-core-link-format-11

[Richard Barnes <[e-mail]>]

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 defines a format for describing a list of resources linked from a server, e.g., an HTTP or CoAP server.  The document suggests the use of TLS or DTLS on the underlying transport for transport security.  My only remaining security concern is that there could be access control concerns as well.  For example, a server might not authorize all clients to see all services, or might provide some clients with different levels of access (e.g., read vs. read/write).  The document already envisions that the list of links will have some dynamism, allowing for filtering based on link attributes.  I would suggest simply noting that servers may want to support HTTP, CoAP, or [D]TLS client authentication and adaptation of the list of returned links based on the client's identity and authorizations.  

Suggested text for Section 6:
"
Some servers may provide resource discovery services to a mix of clients that are trusted to different levels.  For example, a lighting control system might allow any client to read state variables, but only certain clients to write state (turn lights on or off).  Servers SHOULD support authentication features of the underlying transport protocols (HTTP, CoAP, or DTLS/TLS) and allow operators to return different lists of links based on a client's identity and authorization.
"

Non security-related comments follow.

General: This document seems a little bit awkward semantically.  The HTTP Link header is intended to provide links from a given resource (identified by the request URI) to associated resources.  The service described in this document seems to provide a general list of URIs, without a firm idea of what the "source" of these references is.  Indeed, with the "anchor" parameter, it seems like this document allows a service at "/.well-known/core" to act as a general "Tell me about this URI" service, which seems over-broad.  Is this the intent of the WG?  Perhaps the "anchor" parameter should be restricted to relative, not absolute, URIs?  And how is this different from just doing a HEAD request to the URI to get a Link header that would contain the same information?

General: In a similar vein, it seems like this format need not necessarily be restricted to CORE.  Might it not have more general utility for HTTP service discovery?  Really the only impact would be to change the name of the well-known URI from "core" to something more generic.

Section 1.2.1: Quotes or angle-brackets around "/.well-known/core"

Section 1.2.3: The word "filtering" is used here before it is defined.

Section 2: The document hints at conversion from the HTTP Link header a couple of times.  It seems like it would be helpful to lay out the conversion rules in detail.  It seems like you may at least need to convert some things to UTF-8?

Section 2.1: It sounds like the default context URI you're envisioning here is essentially the same as the Origin associated with the scheme, host, and port:
<http://tools.ietf.org/html/rfc6454>

Section 3.1: s/semantically important/application specific semantic/

Section 3.3: The MTU might not be the relevant metric for TCP-based transport (e.g., HTTP)

Section 4.1: It seems like the byte-equality matching here might create a disconnect here between the query patterns you can write and parameters you can have.  In particular, it seems like you might at least need to decode percent-encoding before comparison.  Otherwise, you might have parameters that are un-filterable.

Section 7.3: Should the "Encoding considerations" say something about it always being UTF-8?