Re: [decade] FW: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard

Stephen Farrell <> Thu, 07 June 2012 15:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24B2A21F8894 for <>; Thu, 7 Jun 2012 08:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1WIQAcNp7HPM for <>; Thu, 7 Jun 2012 08:43:10 -0700 (PDT)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id 3B88921F8882 for <>; Thu, 7 Jun 2012 08:43:10 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D7951714E6; Thu, 7 Jun 2012 16:43:09 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1339083789; bh=GlDl/E9LkoEIuT dI5xf3E6zy7mK1dfFe7dr1rtNTy8E=; b=NrJ51XpZ9SVFsOfZk7kIn/FUYp6SU0 PoGT8cNBKmObniDXggRWXTZDhmG3F3RxqNf4fZNjw9i+wv/aZfVub5mhB3eu3RuN ff70qSB9y3geaorAYaZdjZLg2tup5b1i/+VZZW13BkGmUGr1P6p0KRlziQqiOOy8 c7+xzMlx4Pw6E1HtgrlNT9Omdp5QENp8FmW6G6z6vdTlD1UJvOsP/KdDxsLQUqUR UKZyZb4QT63T+tJcS3aHv0Dr0TiIlO/r+1A9WqBPZDMzeJDyv5k3xRM8YuVoJc6g KINBat5FSIx0OOd7sKMZGm2OjKbP6kixks1Vek+DOwGbFkwsHQAKcF6w==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id iehKQcucwrXY; Thu, 7 Jun 2012 16:43:09 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id DCE4F1714E1; Thu, 7 Jun 2012 16:43:08 +0100 (IST)
Message-ID: <>
Date: Thu, 07 Jun 2012 16:43:08 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jonathan A Rees <>
Subject: Re: [decade] FW: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jun 2012 15:43:12 -0000

On 06/06/2012 09:33 PM, Jonathan A Rees wrote:
> As requested I am sending comments on this last call draft to
> I sent them to the authors on 6 May but received no
> reply.

Oh crap - so you did. Apologies for missing that. In the
middle of something now but will get back soon,


> Jonathan Rees
> ---------- Forwarded message ----------
> From: Jonathan A Rees <>
> Date: Sun, May 6, 2012 at 7:57 PM
> Subject: comments on
> To: Alexey Melnikov <>, Barry Leiba
> <>, "S. Farrell" <>,
> "P. Hallam-Baker" <>
> Here are some opinions on
> :
> I think this URI scheme would be a welcome addition to web
> architecture. Wide review should be sought, because this might become
> quite important and if there are problems they will be very difficult
> to fix later.
> I think using .well-known is a good idea.
> I think integration into the ecosystem, such as browser support,
> should be anticipated; for this reason I think content type should be
> elevated from an 'optional feature' to a 'required feature'.
> [i.e. conformant implementations must support it, even if providing
> the content type in the URI is itself optional.]
> If you
> don't do this, you are just encouraging sniffing and privilege
> escalation attacks. Sniffing would be a big step backwards. Better to
> do what the data: scheme does and say that there is a default content
> type of, say, text/plain, and that otherwise the content type ought to
> be specified in the URI.
> Content-type privilege escalation risk (and incorrect sniffing risk)
> should be mentioned in the security considerations section in any
> case.
> Maybe the risk that the host used for retrieval might be spoofing the
> content-type (by providing a bogus content-type in an HTTP response)
> should also be mentioned. (A possible design would be to put the
> content-type (and maybe other headers like Expires:?) in the hashed
> content, to be pulled out into the HTTP response when the content is
> served by an http server and then checked by the client, but I
> understand that this would be a tooling headache.)
> (I don't understand why you want to separate the 'optional' features
> into a separate spec. This made me miss the ct= feature entirely at
> first.)
> I think the documentation should say that the hash and content type
> together identify the resource, and that because the content can be
> verified, the resource can be sought (using the .well-known path, or
> any other path for that matter) from any source that the client thinks
> might have it. The primary and alternate domain name(s), and 'wrapped'
> URLs, are only provided as hints.
> I agree with other commenters on the peculiarity of using // to
> provide the location hint since the named host is not being trusted as
> an authority. I don't understand why the 'primary' location isn't just
> encoded in the query, just like the alternate domain(s) and "wrapped
> URL(s)".  This would have the nice property that you can put the
> identifying parts (i.e. hash and content type) first, and the less important
> location hints parts all together after the identification. The various
> location hints (whether primary or secondary) would go together and
> their similarity would be clearer.
> (Unless I'm misunderstanding something and the part after the //
> actually has status other than a hint?  That would seem to defeat
> the purpose.)
> Jonathan