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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D990511E80A3 for <>; Thu, 7 Jun 2012 12:15:17 -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 n4kvyIMwzKud for <>; Thu, 7 Jun 2012 12:15:17 -0700 (PDT)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id 9D05311E809D for <>; Thu, 7 Jun 2012 12:15:16 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA05C1714E2; Thu, 7 Jun 2012 20:15:15 +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=1339096515; bh=EDt0KwCPXitGxe DC0jOO2XVChZVeJ9c4iqmK0EIFdZs=; b=t0j003sJEMpeGg8nC36og98uTfQcmt 6Suf9Mc1hGmC7f3kLK5nYokqb+D2nNZwfe16HqbEba98Rq/r8qRbUMc1cm9l/lkL 97e83xymO5ZyOLbgpPk3k5IZCMinsP0QqHJhWovIKAG6e8AQZU8OWbe7o01oFTZG mMtvl0E8WIk6rCHNhJlJhaRZtQ9sCSSrDtiu2uixaqE2f8zmg6zMdxX63I58bCdr rFdZ33hHxgoEstjzeTFXGuMe1CG1/HrA6WKB1tdOeHlMAup4e1irOwC7WsYae89J gMzGldMlQQmZv2btkDSld5bvBspliXVp35vlZD3JP6DVGPb9j7fRQhdg==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id Kg-AO03m77q3; Thu, 7 Jun 2012 20:15:15 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 2C9AB1714E1; Thu, 7 Jun 2012 20:15:14 +0100 (IST)
Message-ID: <>
Date: Thu, 07 Jun 2012 20:15:14 +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 19:15:18 -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.

Once again, sorry about that. No idea why I missed responding,
your mail is in my client even. Ah well.

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

I could certainly live with that, and I suspect my co-authors too,
but I'd need to ask 'em. However, we'd like to see more support for
it before doing that. If we only hear from you on this, then I
think leaving it in the other draft would be right. (See below
for why we want to keep that draft.) I guess others have a few
weeks to chime in on this.

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

Would appreciate text if you can offer some. (Always happy to
make the sec. cons. bit better.)

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

Good one. Yep, we should mention this whereever ct= is described.

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

Yep. We thought about it but agree that it gets too complex too
quickly. Maybe with a bit of experience...

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

The intent is to put stuff there if we're not sure if its
ready or needed everywhere. ct= is definitely the main
candidate feature for moving to the "base" spec though.
Some other things (e.g. handling dynamic content) are
way more experimental and should definitely not move
and maybe need more time before we want them in an RFC.

If all this does get popular then the RFCs can be revised later
based on experience in any case. (If nobody cares, then it
won't be a problem:-) So I don't think where things are
documented now is hugely important in the long term.

> I think the documentation should say that the hash and content type
> together identify the resource, 

Well, IMO the hash identifies the resource (if name-data integrity
is verified) so I don't think I agree that the content type is
key for identification. It is for interpretation (or whatever
the right term there is, maybe rendering?) and probably other

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

Absolutely. That's our primary motivation for all this.

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

I think we could argue this (and we did already between the authors;-)
and it'd come down to "pick a way." We did already and wrote code
for that, so we'd prefer to stick with it as-is, especially if there's
no compelling reason to change. I think its likely we can agree that
there's no compelling differences here in whether we use "//" or
a "?loc=" or whatever.


> Jonathan