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

From: David Booth <[email-masked]>
Date: Wed, 02 May 2012 11:32:14 -0400

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 04 May 2012 15:50:30 +0100

Hi David,

Thanks for that. Happy to add some warning text to the
security considerations for this, something like:

"Note that fact that an ni URI includes an domain name in
the authority field by itself implies nothing about the
relationship between the owner of the domain name and any
content referenced by that URI. While a name-data integrity
service can be provided using ni URIs, that does not in
any sense validate the authority part of the name, for
example, there is nothing to stop anyone creating an ni
URI containing a hash of someone else's content so
application developers MUST NOT assume any relationship
between the owner of a domain name that is part of an
ni URI and some matching content just because the ni URI
matches that content."

S

---

From: Larry Masinter <[email-masked]>
Date: Mon, 7 May 2012 17:51:09 -0700

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

Since I'm quoted, I thought I better clarify:

"Persistence" and "Permanently" are acts of intention -- a name is "persistent" or "permanent" if there is a credible SLA by some current and future resolution service, where the service promises to be the authority (forever) for telling everyone what a name means or identifies.

The "ni:" scheme does not provide a persistent name for anything other than chunks of data.

I suppose I should send in an IPR disclosure
http://www.google.com/patents/US5742807
(assigned to Xerox).