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

["Richard L. Barnes" <[e-mail]>]

Hey Zach,

Glad to be helpful.  Sounds like we're basically on the same page; couple of minor responses inline.

> Richard,
> 
> Thanks for the review, see my responses in-line. 
> 
> On Feb 25, 2012, at 12:40 PM, Richard Barnes wrote:
> 
>> 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.
>> "
> 
> Excellent suggestion, I will make a ticket. 
> 
>> 
>> 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.
> 
> The source (context) of the references is meant to be the server itself. Our main use case is the discovery of resources that a web server is hosting. A secondary use case would be to describe relations between resources on the same server (but this is rare for constrained devices). 
> 
>> 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?  
> 
> No, that is not the intent. 
> 
>> Perhaps the "anchor" parameter should be restricted to relative, not absolute, URIs?  
> 
> Yes, this is something that we could certainly do. One aspect that I would point out is that the list of resources that a web server has may also be hosted by a resource directory on behalf of the server (see draft-shelby-core-resource-directory). Currently we are not using the anchor parameter for that, so your suggestion should not be a problem. 
> 
>> 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?
> 
> Of course that would work for the HTTP case (CoAP does not have a Link header), but it would only provide links related to that particular request URI. The intention of this link document available on /.well-known/core is that it returns the resources the server has available (at least the top-level ones that are useful to discover). 

Sorry, I had missed this subtlety.  Now the .well-known approach makes more sense.


>> 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.
> 
> That is the intention that this is equally applicable to both HTTP and CoAP, and in general CoRE is about RESTful environments so I wouldn't think the /.well-known/core really limits anything. Although I would mainly recommend this /.well-known/core mechanism for machine-to-machine web applications, for more general web page discovery there are other technologies already available in the App area.  

If the idea is to describe things on this server, maybe the right tag is "/.well-known/here" :)

Best,
--Richard