Re: the "ni:" URI scheme soon to "last call" in IETF, httpRange-14 and security

BTW, I've been meaning to mention that this "Named Information" (NI)
mechanism *is* actually relevant to the httpRange-14 discussion, because
it addresses the need for persistence of URI definitions that has often
been lamented by Larry Masinter.  In particular, since section 4 of the
NI draft
http://tools.ietf.org/html/draft-farrell-decade-ni-05#section-4
specifies a mapping to http URIs, a URI such as
http://example.com/.well-known/ni/sha-256/f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk 
*permanently* identifies (within the limits of the hash algorithm) a
particular chunk of information.  If that information were a URI
definition, then

Note that this would bypass the dependence on the notion of a "URI
owner" in authoritatively associating a URI with a particular URI
definition, because it does not depend on the URI definition actually
being served from that URI.  I.e., dereferencing the URI would not have
to yield the URI definition (though it would certainly be helpful if it
did).  Thus, anybody could have minted the URI -- not necessarily the
owner of URI's domain.  

This may seem like it would be opening the gates to URI squatting
http://lists.w3.org/Archives/Public/public-swbp-wg/2006Mar/0036.html
but I do not think that is a technical problem in this case, because the
whole purpose of .well-known is to enable a controlled form of URI
squatting, and this is a good example.  

OTOH, if someone else against my wishes published URIs using
http://dbooth.org/.well-known/ni/ as the prefix (i.e., under my domain),
this could raise a security or legal concern, because it may mislead
users of those URIs into thinking that I had sanctioned those URIs and
therefore the content identified by those URIs.  Note also that this
scenario would be significantly different from other cases in which a
scammer squats on my URI space, because in the NI case the URI may
function perfectly well *without* the need for any content to be served
when the URI is dereferenced.  For example, the identified content might
be obtained through a peer-to-peer protocol based solely on its identity
(which is a big purpose of the NI RFC anyway).  Whereas normally, the
scammer would need to be able to actually cause content to be served
from that URI in order to be successful in the scam.  Since users often
look at the domain name in a URI as a means of deciding whether content
is trustworthy, I think this is a significant security issue that should
be noted in NI RFC.  

For example, a scammer could mint an NI URI under my namespace and claim
that it identifies a piece of software that I authored and released.  A
user may see dbooth.org in the domain name of the URI, (wrongly) assume
that the identified software was indeed from me, and allow that
identified software to be downloaded via a peer-to-peer network and
installed, thus compromising the user's system.

It seems to me that warning the user of this problem would not be
sufficient, because most users are not likely to understand the issue in
enough depth to realize that they really, really, REALLY should ignore
the domain name in this particular case, in spite of the fact that in
most other uses of URIs, the domain name is relevant to consider.  So
perhaps one way to avoid this problem would be to avoid displaying the
domain name to the user at all.   Or maybe someone else will have a
better idea of how to mitigate this risk.

Aside from the above, which I will forward separately to the IETF list,
I do not know of any particular input that the TAG should give to the
authors of this proposed RFC.  It looks to me like a very nice piece of
work.

David

On Tue, 2012-05-01 at 15:40 -0700, Larry Masinter wrote:
> I think we talked about this under "naming things with hashes" (in
> this case, not "#" hash-mark fragment identifier, but rather
> hash-of-content).
> 
> http://tools.ietf.org/html/draft-farrell-decade-ni-05
> 
> I suggest looking at how this spec uses the word "resource". "
> information-centric networking" might also be an interesting topic as
> we talk about "local storage" also (see references).
> 
> Larry
> 
> 
> -----Original Message-----
> From: uri-review-bounces@ietf.org On Behalf Of Stephen Farrell
> Sent: Monday, April 30, 2012 8:57 AM
> To: uri-review@ietf.org
> Cc: Barry Leiba; draft-farrell-decade-ni@tools.ietf.org
> Subject: [Uri-review] Two new URI schemes for review
> 
> 
> Hi,
> 
> We have a draft [1] that requests two new URI schemes.
> 
> The core WG are likely to want to use these we think
> and possibly decade, but they're intended to be generally
> useful as well.
> 
> Barry Leiba is planning to AD sponsor this and Alexey
> Melnikov will be shepherding so if you can cc them ase
> well as the authors on any questions or comments that'd
> be good.
> 
> I hope the plan is to IETF LC this soon, once this
> review and the .well-known registration review are
> done.
> 
> Thanks,
> Stephen.
> 
> [1] http://tools.ietf.org/html/draft-farrell-decade-ni-05
> _______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review
> 
> 
> 

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Wednesday, 2 May 2012 15:19:44 UTC