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

Zach Shelby <zach@sensinode.com> Thu, 08 March 2012 19:46 UTC

Return-Path: <zach@sensinode.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2C121F84F5; Thu, 8 Mar 2012 11:46:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93fIbXn75YNn; Thu, 8 Mar 2012 11:46:40 -0800 (PST)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 469DB21F84E0; Thu, 8 Mar 2012 11:46:39 -0800 (PST)
Received: from [192.168.1.103] (178-55-87-130.bb.dnainternet.fi [178.55.87.130]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q28JkFgW003139; Thu, 8 Mar 2012 21:46:16 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Zach Shelby <zach@sensinode.com>
In-Reply-To: <3E9A3BC9-6AEB-4E03-A053-5E7A172DA4E7@bbn.com>
Date: Thu, 08 Mar 2012 21:46:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F666D01D-0962-44E5-9AF7-85C20673D3F5@sensinode.com>
References: <3E9A3BC9-6AEB-4E03-A053-5E7A172DA4E7@bbn.com>
To: Richard Barnes <rbarnes@bbn.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Thu, 08 Mar 2012 14:34:34 -0800
Cc: draft-ietf-core-link-format@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-core-link-format-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 19:46:41 -0000

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

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

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

OK.

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

OK.

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

Yes, I will make a ticket to open up that explanation. 

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

Yes, I think that would be a useful reference (Section 4 of RFC6454). So the default context URI is the Origin of the requested URI. I will make a ticket to add that reference unless someone thinks that would be a bad idea. 

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

OK.

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

Right. Still would like to recommend that even for HTTP knowing the size ahead of time would be useful. 

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

OK, I will work with Carsten to figure that out. 

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

Peter, I think we discussed that with both you and Alexey at some point during earlier reviews, and the end result was just to say "Binary data". Anyone remember why we didn't mention UTF-8?

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297