Re: [apps-discuss] Indicating hash size in 'ni' URIs

[Stephen Farrell <[e-mail]>]

Hiya,

I think the main thing to keep in mind is that we don't
want people to make the mistake of thinking two names are
the same when they aren't. In other words a name with a
32 bit truncated sha-256 hash is not the same as a name
with the full 256 bits of hash output, even if the hash
value for one is a prefix of that for the other.

The reason being that if an application treats those the
same then that'd open up a bunch of attacks. For example,
if I publish an object with the full hash, then I probably
(in general) don't want some other application to treat a
name with just the first 32 bits of that as referring to
the same thing, since the 32 bit name will have lots of
colliding objects. If this stuff gets used, there will
be many cases where names will occur more than once in
application protocols, and it'll be unpredictable which
instance of the name will be used for name-data integrity
checking. (Maybe we ought add a bit more security
considerations text to explain that better, suggestions
welcome.)

Now, IMO, the syntax we have makes that mistake less likely,
whereas your proposal makes it more likely to happen, due
to developer carelessness or misunderstanding.

We also have code [1] that implements the current syntax,
so for us at least, we'd want to see a benefit to switching,
and I only see a downside right now. That code is very
early, so it's not a major major deal, but I'd not want
to break stuff for fun, and given that we've implemented
this in a bunch of languages, it'd be a chunk of work.
(Developer enthusiasm, after many months of discussion
and ppt engineering lead to a burst of coding activity
resulting in c, ruby, java, php, python, clojure and a
few application examples, including wget and curl all
of which do the ni URI as per the current draft:-)

On 05/09/2012 02:02 AM, Manger, James H wrote:
>>>> I would still rather ditch the truncation length from the alg names.
>  
>>> I'm with James on this one.
>>> ... The example of a truncated stream cipher seems contrived to me.
> 
>> Not to me.
>>
>> I think that omitting the size would mean that anyone using
>> these would need to go think about potential truncation attacks,
>> and having to do that is bad, since most times they won't do
>> it at all and even if they do, those attacks, if they apply,
>> will be likely be very subtle. So even if you try figure it
>> out, you may not get the analysis right. Avoiding all that
>> is just better IMO.
> 
> I am trying to understand the truncation attacks you are concerned about. Would an example be an HTTPS web connection that abruptly stops mid stream? All the received TLS records are properly encrypted and have valid MACs. However, only half of the HTML page has been delivered: it might end "<script src='ni://example.com/sha-256;f4OxZX". Somewhere in the receiver's stack it knows truncation has occurred (the TLS and HTTP and layers didn't close properly), but the higher layer ignores that and interprets the content anyway. In this example, a browser (which is very lenient) accepts the incomplete <script> tag and acts on the wrong (truncated) URI.
> 
> The fault is not with the 'ni' URI. Solving this situation would require all protocols (not just 'ni' identifiers) to be "prefix-free" (eg no prefix of a protocol can be meaningful). That is not realistic.

Right. I did say its a corner case at best, but we don't know
what protocols will use these names. And maybe one of those will
allow truncation attacks. I'd really rather not have to think
about it. (Mind you, if the name is just sent encrypted in a
stream cipher without integrity, then swapping bits can also
switch sha-256-96 to sha-256-32 easily enough;-)

> 
> An 'ni' URI can have query parameters. Couldn't a truncation attack strip those regardless of whether the hash length is in the alg name? Why isn't that a problem?

Whether that matters is down to the application protocol I
think. For the base spec, we just say that the names are
the same, iff the hash alg, length and value are the same.

> 
>> Additionally, if we took out the length then we'd have to
>> figure whether or not (or when, yuk) ni:///sha-256;abc is the
>> "same" as ni:///sha-256;abcdef and even if we declare that its
>> never the same, that's something people are liable to get
>> wrong, since sometimes both would actually refer to the same
>> thing. Yuk yuk yuk;-)
> 
> Implementations are just as likely to consider that the following are the "same":
>   ni:///sha-256-32;abcdef
>   ni:///sha-256-64;abcdefghijk

I guess I just disagree about that.

strncmp(a,b,min(len_a,len_b)) would not treat them as equal
with the current syntax but would with your suggestion.

> If a truncation attack really needs to be defended against, we should specify that the output length (and algorithm) are inputs to the hash. For example, Truncate_to_n(Hash(alg || n || content)).

We thought about that but didn't go for it, because it'd
easily get over complicated, e.g. you'd maybe want to also
include the query string, authority etc. and there didn't
seem to be much benefit from that level of complexity.
It'd also mean that you couldn't just create these
names for (large sets of) things for which you've already
calculated the hashes e.g. if you had a large image library
already using sha-256 hashes in their URLs then with
the above it'd not be possible to use the .well-known/ni
URL (and presumably an HTTP 30x re-direct) to de-reference
the name. Allowing that seems like a good thing.

Having said all that, if it turns out that you're right
and we're wrong, then it'd not be too hard to define and
register a new hash function that'd work as you suggest,
but I just don't see it being more useful right now and
do worry about it being less safe.

Cheers,
S.

[1] http://sourceforge.net/projects/netinf/

> --
> James Manger
>