Re: [websec] Digest URI scheme

[Phillip Hallam-Baker <[e-mail]>]

Come to think of it, didn't you send this to us when we first proposed
the ODI thing in CAA v1.0?


I really don't care about the specifics of the design half so much as
we end up with having one, not three.

Only real issue for me is that it has to fit in URI type slots. The
scheme I was thinking of would be a pure URN scheme, your proposal
includes URL like things.

Clearly, your scheme is a better way to reference external content in
a resolvable format. I have to go look at the URN and URI specs again
in detail.


I note that you have a content type, which I have but someone here was
objecting to. I consider the content type to be essential meta-data
for obvious security reasons.


You want to share your design issue here or should we go offline, rev
the proposal and come back?




On Thu, Sep 29, 2011 at 6:00 PM,  <[e-mail]> wrote:
>
> <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
>>
>
>
>



-- 
Website: http://hallambaker.com/