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

["Manger, James H" <[e-mail]>]

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

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?



> 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


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

--
James Manger