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

From: Jonathan A Rees <[email-masked]>
Date: Wed, 6 Jun 2012 16:33:36 -0400

As requested I am sending comments on this last call draft to
[email-masked]. I sent them to the authors on 6 May but received no
reply.

Jonathan Rees

---------- Forwarded message ----------
From: Jonathan A Rees <[email-masked]>
Date: Sun, May 6, 2012 at 7:57 PM
Subject: comments on http://tools.ietf.org/html/draft-farrell-decade-ni-06
To: Alexey Melnikov <[email-masked]>, Barry Leiba
<[email-masked]>, "S. Farrell" <[email-masked]>,
"P. Hallam-Baker" <[email-masked]>

Here are some opinions on
http://tools.ietf.org/html/draft-farrell-decade-ni-06 :

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 07 Jun 2012 16:43:08 +0100

> [email-masked]. I sent them to the authors on 6 May but received no

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

Cheers,
S

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 07 Jun 2012 20:15:14 +0100

> [email-masked]. I sent them to the authors on 6 May but received no

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

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

> should be mentioned in the security considerations section in any

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

> should also be mentioned. 

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

> (A possible design would be to put the

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

> into a separate spec. This made me miss the ct= feature entirely at

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.

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

> and that because the content can be
> might have it. 

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

> The primary and alternate domain name(s), and 'wrapped'

Yes.

> actually has status other than a hint?  That would seem to defeat

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.

Cheers,
Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 08 Jun 2012 12:21:44 +0100

Hiya,

On 06/08/2012 01:35 AM, Jonathan A Rees wrote:
> On Thu, Jun 7, 2012 at 3:15 PM, Stephen Farrell
> <[email-masked]> wrote:
>>
> OK, I suspect I can find other W3C TAG members who would agree; will circulate.

Great. Just note though that in figuring rough consensus its
not really useful for a bunch of (esp. previously unknown)
people to just say "+1" to something. A note like yours that
shows they've read the draft and have their own comment is
much more useful. (Its happened in the past that quite
well-meaning folks have jumped in like that and with no
context it makes it hard for anyone to figure what to make
of things.)

> 
> It is certainly strongly promoted by the W3C web architecture document, see
> http://www.w3.org/TR/webarch/#internet-media-type
> so I think I have W3C consensus (as of 2005) behind my claim.

Well I could argue that that says that protocols SHOULD
do stuff and we're just defining the URI here and not a
protocol. But let's see if we get more input on this.

> Hmm. Hot potato.
> Maybe something can be derived from Adam's draft
> http://tools.ietf.org/html/draft-abarth-mime-sniff-06
> which I assume you've seen...  obviously I'd prefer you do the
> drafting, but will consider myself pressured.

I look forward to seeing that text then:-)

>> Good one. Yep, we should mention this whereever ct= is described
> 
> No, this is a threat even if ct= isn't used. Suppose that the document
> is intended as an unscriptable media type, but the (malicious) server
> sets the content-type: header in the response to a scriptable type.
> Not good. I think this threat is described in Adam's draft.

Ta.

> Hmm... if this spec takes off like I hope it will, you will have more
> influence than you think now, so the implicit messages will be
> important... by putting ct= in a separate document you're saying that
> it's not important, and you'll encourage implementations that use
> sniffing instead of some rational way to convey the media type.

Maybe, maybe not. What's more important is what gets used
IMO. Again, let's see if we get more input.

> Well maybe we're quibbling over terminology, but in the HTTP spec and
> in all the W3C documents, the media type is part of the resource (or
> "representation" in HTTPbis; the distinction is immaterial for your
> URI scheme), and therefore part of its identity. 

Immaterial for this scheme is the bit that I like:-) So yes
we don't need to solve any philosophical problems now.

> It would be
> unfortunate to introduce an incompatible world view into the RFC
> corpus.

The RFC corpus has lots of good and lots of dodgy stuff and is
not a bible.

> Well, you have a chance to fix this now, and it will be impossible to
> fix later. 

Its true we won't be able to change this later but not true
IMO that any fix is needed, now or later.

> Using // is contrary to RFC 3986, which very clearly says
> "governance of the name space defined by the remainder of the URI is
> delegated to that authority". This is certainly not what this URI
> scheme does, so use of // is contrary to the appicable normative spec.

I disagree. The full quote there is:

  "Many URI schemes include a hierarchical element for a naming
   authority so that governance of the name space defined by the
   remainder of the URI is delegated to that authority (which may, in
   turn, delegate it further)."

There are no SHOULDs nor MUSTs there with which we're not
complying, and "many" != "all." Yes, ni URIs differ in some
respects from HTTP URLs, but if they didn't then this draft
wouldn't be needed, so that's ok.

Cheers,
S.

> Best

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Jun 2012 14:54:18 -0700

One small comment, that I know the authors are aware of...

> I think using .well-known is a good idea.

I think that using .well-known is a bad idea.

This imposes an unnecessary restriction on the deployment of
resources.  /.well-known/ is a space that can only be deployed to by
an administrator of the system.  By identifying specifically where the
resource might live (potentially with more than one URL), this avoids
the deployment issue.

Yes, I am aware of the "extensions".

And:
> (a lot of other things)

I agree with all of this, the authority thing, the content-type thing.
 All of it.  (And none of the rebuttal.)

Nit:
The draft makes some strange statements about redirects.

   Put another way, a server SHOULD return a 30x response when a .well-
   known/ni URL is de-referenced.

Requiring a compliant HTTP implementation that follows redirects is
sufficient.  What the server does to serve this request is the
server's business.  Redirects seem likely, but 2119 language for the
server is not necessary for interoperation.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 09 Jun 2012 01:06:33 +0100

Hi Martin,

> I think that using .well-known is a bad idea.

Ok. Opinions vary.

> Yes, I am aware of the "extensions".

I don't get what you mean above. If its something that
implies a change, I don't know what change.

>  All of it.  (And none of the rebuttal.)

So the probability of us being completely correct in all this is
probably infinitesimally small, but equal to the probability
of us being completely wrong. That would imply that our rebuttals
are not completely wrong and hence you are equally wrong in
saying "all" and "none" above. (Isn't sophistry great:-)

Anyway, I take that as another +1 for adding ct= to this draft
which is fine. I'm starting to think that might be a good plan.
Let's see if others (dis)agree during the rest of IETF LC.

I also take that as another claim that our use of the
authority field is somehow "wrong" for what seem to me to
be near-mystical reasons, with no compelling argument offered
as to any bad effects at all ensuing. I'm still entirely happy
that our current design is good enough as-is. For me, running
code is a winner in that part of the argument.

> server is not necessary for interoperation.

Good point. I've tweaked that a bit in response to Bjoern's
comments, but your suggestion above is better than what I
have now so I'll work that in. (Actually, is client support
for 3xx mandatory according to 2616? Not sure myself.)

Thanks,
S.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 08 Jun 2012 20:43:48 -0400

Add me as a +1 for the idea that content-type is important for this.
I tend to agree with the arguments given so far. Namely, for some
important use cases you're going to want to know the content type and
guessing is  really a bad idea.

That said, there are security considerations associated with specifying
a content type too.  I'm particularly imagining a situation where some
sort of deep inspection security appliance uses a different procedure
for deciding what kind of foo it is than the ultimate application. One
guesses based on byte stream another looks at a content type.  This is
well known; it's not new; it's probably even so documented that any
reasonably current set of MIME security considerations already includes
a reference.

I agree that your draft does not use the authority portion of a URI
consistent with section 3.2 of RFC 3986. The authority separates the
namespace exactly the way it doesn't in your scheme. It's a naming
hierarchy.  My main concern is whether the relative reference algorithm
described in section 5/4.2 of RFC 3986. In particular take a look at the
last part of section 1.2 of RFC 3986 regarding the disallowing of
/. Consider how you want relative references in an HTML document
resolved through a ni: URI to work.  I don't think your use of authority
provides good results. However I'm not sure that better results would be
achieved without hierarchy.  I hope though that these comments will help
inject some ways of reasoning about authority that are less mystical and
that lead to more practical discussion.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 09 Jun 2012 02:45:23 +0100

Hi Sam,

> guessing is  really a bad idea.

Thusly counted:-)

> reasonably current set of MIME security considerations already includes

My only real concern with adding this is the issue of complexity
related to c14n of input to the hash function. While CMS does (I
think) define that well, imposing that burden on anyone that might
want to write code that validates name-data integrity is an issue.
Anyway, if we want to add it we'll look that over and figure how
it might best be done.

> consistent with section 3.2 of RFC 3986. 

I honestly don't get that. I think we are "consistent" with 3986
(there being no MUST/SHOULD with which we're in conflict afaik)
but the authority field here is not identical to that for HTTP
URLs. And that's ok.

> The authority separates the
> namespace exactly the way it doesn't in your scheme. 

Yes there are differences and maybe we ought try describe that
somehow.

> It's a naming

Thanks.

I think your comment about relative URIs is fair and we maybe ought
say there are no such things for ni URIs. (Or however that kind of
thing is stated best).

I guess a sentence or two about relative URIs would be worthwhile
and I'll ponder that.

S.

---

From: [email-masked]
Date: Fri, 08 Jun 2012 22:11:00 -0400

Stephen Farrell <[email-masked]> wrote:

Hi Sam,

Thusly counted:-)

Thanks.

S.

---

From: Jonathan A Rees <[email-masked]>
Date: Thu, 7 Jun 2012 20:35:43 -0400

Hmm. Hot potato.

URI scheme), and therefore part of its identity. It would be

fix later. Using // is contrary to RFC 3986, which very clearly says

Best
Jonathan

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 12 Jun 2012 18:49:33 +0900

Hello Stephen, others,

>>>> From: Jonathan A Rees<[email-masked]>
>>>> To: Alexey Melnikov<[email-masked]>, Barry Leiba
>>>> <[email-masked]>, "S. Farrell"<[email-masked]>,
>>>> "P. Hallam-Baker"<[email-masked]>
>>>>

> protocol. But let's see if we get more input on this.

Sophistry is great, but security is better :-).

Seriously, (1) URIs can be seen as (extremely small) protocols, (2) they 
are used in many protocols and formats, which might be better served 
with having the content type being taken care off rather than having to 
do it on their own, and (3) in order for the protocols to do the right 
stuff, they need the right information.

> wouldn't be needed, so that's ok.

In my opinion, the decision on whether to use the authority part or not 
is probably more a theoretical one than a practical one. Either way 
seems to be fine. Strictly speaking on abstract "authority" grounds, the 
mailto: URI could have used // because mumble.net is the authority for 
mail to [email-masked].

But I agree with Jonathan that once we start putting other information 
such as full URIs from which the resource can be retrieved, alternate 
'authorities' where it may be available, and so on, after the hash, then 
putting all that stuff there seems cleaner.

Regards,   Martin.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Jun 2012 11:09:33 +0100

Hi Martin,

On 06/12/2012 10:49 AM, "Martin J. Dürst" wrote:
>>>>> Subject: comments on
>>>>> http://tools.ietf.org/html/draft-farrell-decade-ni-06

:-)

> stuff, they need the right information.

I'm looking into this since a number of people seem to
want it and it does have some real value.

My main concern is with adding it is to see if it can be
done without over-complicating a basic implementation. The
danger would be that we'd say "you MUST be able to verify
name-data integrity for any MIME Content Type" which'd get
hard quickly.

I expect we'll shoot out a proposal for how ct could be
included at the end of IETF LC. (We may still argue
against, but we'll likely float a version including it
in any case.)

> putting all that stuff there seems cleaner.

Right. A few people seem to prefer it like that. We prefer it
as is. I agree with you that this isn't significant so I'd
really rather go with the running code here.

Cheers,
S.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 12 Jun 2012 19:43:54 +0900

Hello Stephen,

> say there are no such things for ni URIs. (Or however that kind of

You can't say that. It's perfectly okay to have an HTML document like this:

<html>
  <head>
    <title>ni: relative URI test</title>
    <base href="ni://example.com">
  </head>

  <body>
    <p>Please check <a href="sha-256;f4OxZX...">this document</a>.
      And <a href="sha-256;UyaQV...">this other document</a>.
      And <a href="sha-256-128;...">this third document</a>.
    </p>
  </body>
</html>

("..." used for brevity). What the browser will try to interpret when 
the links are activated is:
ni://example.com/sha-256;f4OxZX...
ni://example.com/sha-256;UyaQV...
ni://example.com/sha-256-128;...

If you don't think that makes sense, then you might just leave it to 
users to not use it that way. On the other hand, if you think that's 
actively harmful (I couldn't come up with a reason for that), then you 
have to change to the form without //.

[Well, actual browser behavior is a bit more mixed:

IE does what's explained above, and tries to go to the address, but says 
that this page can't be displayed.

Safari uses the above resolved URIs when asked to copy the link, and 
also tries to follow the link saying that the page can't be opened.

Mozilla doesn't even show the link texts as links, nor allows to 
activate them, probably because it decides that it doesn't want to 
disappoint the user when she clicks.

Chrome shows the underlined links, but doesn't want to show any 
destination when hoovering. When activating, it goes to about:blank.

Opera shows and tries to go to ni://sha-256;f4OxZX... and similar, i.e. 
it seems to drop the authority, possibly because it doesn't have ni: 
registered as a hierarchical scheme. But that would be fixed when the 
scheme is getting implemented.]

> I guess a sentence or two about relative URIs would be worthwhile

Yes, please do. I'm willing to check it.

Regards,    Martin.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Jun 2012 12:00:17 +0100

Hiya,

Ah, ok I get it now. I'll look back at that again,

Ta,
S

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Jun 2012 12:08:15 +0100

So would it work to add this:

"
   Note that relative ni URIs can occur, for example as shown in
   Figure 5.  In such cases, user agents MUST construct the absolute URI
   as they would in the case of an HTTP URL, that is, in the example
   shown the absolute URI for "this third document" would be
   "ni://example.com/sha-256-128;...".

     <html>
      <head>

      <body>

                Figure 5: Example HTML with relative ni URI

"

Better suggestions welcome.
Ta,
S.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 13 Jun 2012 15:28:50 +0900

Hello Stephen,

>     "ni://example.com/sha-256-128;...".

This looks fine, except that it contains a MUST when it can just refer 
to RFC 3986. So I would suggest the following text:

    Note that relative ni URIs can occur. In such cases, the algorithm
    in Section 5 of RFC 3986 applies. As an example, in Figure 5, the
    absolute URI for "this third document" is
    "ni://example.com/sha-256-128;...".

>          <p>Please check<a href="sha-256;f4OxZX...">this document</a>.
>            And<a href="sha-256;UyaQV...">this other document</a>.
>            And<a href="sha-256-128;...">this third document</a>.
>          </p>
>        </body>
>       </html>
>

I tried to look "Ta" up on the Web, but there were just too many 
potential explanations. What are you using it for?

Regards,   Martin.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Jun 2012 10:47:11 +0100

>    "ni://example.com/sha-256-128;...".

works for me

> potential explanations. What are you using it for?

Ta == Thanks :-)

Ta,
S.

---

From: Jonathan A Rees <[email-masked]>
Date: Tue, 12 Jun 2012 11:23:19 -0400

> Anyway, if we want to add it we'll look that over and figure how

OK, I agree that's an issue. My feeling is that it's not much of a
burden, and to the extent it is a burden it's important to take on.
I'm not sure but wouldn't the burden just be: If (1) the client is
sensitive to media type, and (2) it gets a media type from the server,
and (3) ct= is provided, and (4) they don't match, you either ignore
the type from the server, or treat it as spoofing.  Otherwise - you
just do what you would have done, had ct= not been mentioned in the
spec. Clients or protocols for which either (1) or (2) doesn't apply
are unaffected; if (1-2-3) apply then the situation is important.

(Come to think of it the  same consideration applies to data: ... of
course it's not common to use a data: URI as the request URI in an
HTTP request.)