Re: [Uri-review] the "ni:" URI scheme soon to "last call" in IETF -- security concern

[David Booth <[e-mail]>]

Hi Stephen,

This looks like a very nice piece of work.  However, I think there is an
additional security concern that should be addressed, as described
below.  (You can ignore the first three paragraphs of the message below,
as they address a different topic.)

Thanks,
David

-------- Forwarded Message --------
From: David Booth <[e-mail]>
To: Larry Masinter <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: the "ni:" URI scheme soon to "last call" in IETF,
httpRange-14 and security
Date: Wed, 02 May 2012 11:29:24 -0400

On Wed, 2012-05-02 at 11:19 -0400, David Booth wrote:
> 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

. . . that URI would be permanently associated with that particular URI
definition.  

[Sorry I forgot to finish that sentence!]

> 
> 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: [e-mail] On Behalf Of Stephen Farrell
> > Sent: Monday, April 30, 2012 8:57 AM
> > To: [e-mail]
> > Cc: Barry Leiba; [e-mail]
> > 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
> > [e-mail]
> > 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.