Re: [websec] Digest URI scheme

[[e-mail]]

<no hats>

I agree with the motivation but not the design. A while ago
I posted my idea for a design for this. [1] It may become a
work item for the DECADE WG, ... or not, we'll see.

S.

[1] http://tools.ietf.org/html/draft-farrell-ni-00


> As I mentioned previously, the need to refer to a static data object
> by means of a digest comes up frequently. Rather than re-invent the
> mechanism for creating a reference each time we need one, it would be
> better if we had a single format that could be re-used.
>
> We used to have this back in the days when we trusted MD5 since we
> used that everywhere as a 'fingerprint'. Then things got muddy after
> the Dobertin attack and it became SHA1 and MD5. With SHA2 vs SHA3 it
> will be very muddy.
>
> This would be relevant to the cert pinning debate.
>
>
> I wrote a draft making the proposal:
>
> http://www.ietf.org/id/draft-hallambaker-digesturi-00.txt
>
>
> On the digest front the objective would be to make it possible to use
> the URI format with any digest at all in theory but strongly encourage
> people to only use the digests IETF is confident in. Use of OIDs as
> the identifier has the nice property that anyone can get an identifier
> to distinguish their algorithm from other people's but getting an OID
> does not produce any paper trail that can be used to imply an IETF
> endorsement.
>
> We could add in support for the text based identifiers as well, but
> since the only identifiers that I would want to encourage are SHA2 and
> SHA3, I don't see a need. For all applications that make sense it is
> going to be perfectly OK to simply generate the prefix for the
> identifier part as a static array of octets and append / verify it as
> such whenever it is needed. I do not see any need to write ASN.1
> handling code for these apps :-)
>
>
> The basic idea here is that we need to allow for algorithm agility and
> to prevent a content substitution attack. So imagine that we have web
> page A linking to some off site static content via a digest. Site A
> regards the static content as a PNG and has checked out the page and
> it works fine. What they don't know is that buried in the PNG there is
> some malicious Jscript and if the content server delivers it as
> application/script the result will be a series of syntax errors (that
> are silently ignored because the app is stupid)  and then it finds the
> malicious code... ooops.
>
> OK, so maybe not an attack that you find to be a worry in every
> circumstance, but it is definitely an attack vector we should address
> in a general purpose crypto building block.
>
>
> Having produced a static building block like this it is very easy to
> generate a fingerprint for a static data object in a cut and paste
> ready format. I don't need a separate tool to generate digest
> identifiers for WebSec vs other applications. In terms of ease of use
> we get back to what things were like when we used MD5 fingerprints.
>
> It is also quite easy to make use of truncated fingerprints should
> that be necessary. For example, to put on a business card.
>
> --
> Website: http://hallambaker.com/
> _______________________________________________
> websec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/websec
>