Subject: [websec] Digest URI scheme

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 27 Sep 2011 13:10:54 -0400

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/

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 27 Sep 2011 17:22:54 -0700

> http://www.ietf.org/id/draft-hallambaker-digesturi-00.txt

If the WG wants a URI that meets the objectives that Phill laid out (and I think that many of those are good objectives), something much simpler without any ASN.1 in it would be better. I'd be happy to write a much simpler proposal if the WG wants.

--Paul Hoffman

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 28 Sep 2011 10:30:22 +1000

>If the WG wants a URI that meets the objectives that Phill laid out (and I think that many of those are >good objectives), something much simpler without any ASN.1 in it would be better. I'd be happy to write >a much simpler proposal if the WG wants.
>
>--Paul Hoffman

Yes, a text format would be easier to handle, learn, edit, and understand.

Tacking a digest onto URIs that do provide a means of resolution might be more useful.

P.S. The sample certificate in draft-hallambaker-digesturi-00.txt section A.1 has a negative modulus!

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 28 Sep 2011 03:16:08 +0200

>Tacking a digest onto URIs that do provide a means of resolution might be more useful.

That sounds like <http://en.wikipedia.org/wiki/Metalink>.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 28 Sep 2011 03:13:34 +0200

* Paul Hoffman wrote:
>If the WG wants a URI that meets the objectives that Phill laid out (and
>I think that many of those are good objectives), something much simpler
>without any ASN.1 in it would be better. I'd be happy to write a much
>simpler proposal if the WG wants.

That was my initial reaction aswell, but I am not entirely sure what the
objectives are considering that they seemingly lead to discussing ASN.1
and DER and OIDs in the proposal. I do note that there have been many
initiatives to draw digests into URI space, the "urn:sha1:" convention
is popular for instance but currently unregistered.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Gervase Markham <[email-masked]>
Date: Wed, 28 Sep 2011 10:32:06 +0100

> does not produce any paper trail that can be used to imply an IETF

But it also makes the identifiers less human readable and much longer
than they could otherwise be.

> SHA3, I don't see a need. 

Why does it take so many bytes to determine between a very small number
of options?

Worrying about clashes in the text-based identifiers people use seems
somewhat unnecessary. How many hash algorithms with the same name (or
without an obvious canonical name) are there? If this was really a
problem, we could have a microformats-like wiki registry:
http://microformats.org/wiki/existing-rel-values

> For all applications that make sense it is

Then why use ASN.1 at all?

Counter-proposal: how about:

digest:SHA1,<base64 string of digest>

Like a data: URL, except without the option for ASCII/URL encoding:
http://en.wikipedia.org/wiki/Data_URI_scheme

For bonus points, allow multiple comma-separated digests to ease
algorithm migration.

Simple :-)

Gerv

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 28 Sep 2011 19:52:20 +0900

I fully agree with others that a textual form is better. That's the 
tradition of URIs. It's much easier to implement, write tests, and so 
on, and won't unnecessarily scare people away.

Regards,    Martin.

P.S.: As a nit (but a strong one), the current draft has "DIGEST:" all 
over the place. But RFC 3986 
(http://tools.ietf.org/html/rfc3986#section-3.1, second paragraph) says:

    Scheme names consist of a sequence of characters beginning with a
    letter and followed by any combination of letters, digits, plus
    ("+"), period ("."), or hyphen ("-").  Although schemes are case-
    insensitive, the canonical form is lowercase and documents that
    specify schemes must do so with lowercase letters.  An implementation
    should accept uppercase letters as equivalent to lowercase in scheme
    names (e.g., allow "HTTP" as well as "http") for the sake of
    robustness but should only produce lowercase scheme names for
    consistency.

which fully matches current practice.

On 2011/09/28 18:32, Gervase Markham wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 28 Sep 2011 17:55:43 +0100

<hat="individual">
I would also agree with the textual form. And don't see any reasons for 
using ASN.1 in this instance.
For the alg identifier, there might be reasons for using values from a 
registry, as that gives extendibility and at the same time the ids 
reference their specifications (which is superior to just using a name 
and hope that everybody understands it the same way, i.e. uses the same 
specification).

<hat="wg chair">
like the idea and it could be within websec charter if we as a WG want 
to work on that.
If you like we could have a discussion on that in Taipei (volunteers 
please contact me in the next few days so I can make sure the slot in 
the agenda is sufficient)
For drafts, please consider that there are cut-off dates for Taipei.

Kind regards, Tobias

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Sep 2011 12:27:45 -0400

> than they could otherwise be.

It is a message digest, how readable would you like it to be?

We can easily put some of the packing in ascii:

DIGEST:SHA-256:text/plain:eiwoeiwoiejfoiwejfiojefiojweoifj==

You are still going to end up with an unreadable blob at some point.

> Why does it take so many bytes to determine between a very small number

Because of the vanity crypto problem.

> http://microformats.org/wiki/existing-rel-values

We have an IANA registry already.

> Then why use ASN.1 at all?

Because the crypto APIs use ASN.1 as the identifier that they key off.
So if you introduce a text based identifier they have to track two
different registries.

> digest:SHA1,<base64 string of digest>

It still needs to at least have an option for specifying the content
type, this could be made optional though.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Sep 2011 12:33:34 -0400

OK, I will rev the draft to make it text identifiers.

I am aware of the urn:sha1 stuff. I would prefer to avoid having every
digest become a urn scheme, plus there are issues with the legacy.

I will also check up on the uri syntax issues. Base64 uses two non
ascii characters and these need to be checked for legality. There is
some other house cleaning stuff.

We might also reduce the length of the scheme name maybe? digest is 6
chars, do we need them all? I would also like to see if we can ditch
the urn: prefix legally, it was bogus from the start, names and
locators are not disjoint categories.

On Wed, Sep 28, 2011 at 12:55 PM, Tobias Gondrom
<[email-masked]> wrote:
> registry, as that gives extendibility and at the same time the ids reference
> their specifications (which is superior to just using a name and hope that
> everybody understands it the same way, i.e. uses the same specification).
>
>
> <hat="wg chair">
> like the idea and it could be within websec charter if we as a WG want to
> work on that.
> If you like we could have a discussion on that in Taipei (volunteers please
> contact me in the next few days so I can make sure the slot in the agenda is
> sufficient)
>> tradition of URIs. It's much easier to implement, write tests, and so on,
>> and won't unnecessarily scare people away.
>>
>> Regards,    Martin.
>>
>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Sep 2011 12:44:15 -0400

If we go for text, we should use:

http://www.iana.org/assignments/dssc/dssc.xml

Registration Procedures : First Come First Served
Reference : [RFC5698]

Here are the digest algs:

md2	1.2.840.113549.2.2	[RFC3279]
md5	1.2.840.113549.2.5 [RFC3279][RFC4051]
sha-1	1.3.14.3.2.26 [RFC3279][RFC4051]
sha-224	2.16.840.1.101.3.4.2.4 [RFC4055][RFC4051]
sha-256	2.16.840.1.101.3.4.2.1 [RFC4055]
sha-384	2.16.840.1.101.3.4.2.2 [RFC4055][RFC4051]
sha-512	2.16.840.1.101.3.4.2.3 [RFC4055]

I would presume that sha-3-* will be defined in due course.

So there would have to be text to strongly discourage use of sha-1 and
very strongly discourage md2 and md5.

I don't think we could prohibit use while relying on an extensible registry.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 29 Sep 2011 09:52:49 -0700

> type, this could be made optional though.

Why is the content type important for your use cases? It is not inherently linked to the content that you are digesting. There are plenty of types of content that have multiple conflicting MIME types due to history. I foresee that a system that is reading one of these digest: URIs might fail if the content type is not what it expected.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 29 Sep 2011 09:55:40 -0700

> http://www.iana.org/assignments/dssc/dssc.xml

+1

> very strongly discourage md2 and md5.

+1. Even just "very strongly discourage" all three.

--Paul Hoffman

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 29 Sep 2011 19:19:24 +0100

>> http://www.iana.org/assignments/dssc/dssc.xml
+1. Makes sense.

> +1. Even just "very strongly discourage" all three.

+1 on very strongly discourage md2, md5.
Not sure whether we need to explicitely also "very strongly discourage" 
sha-1.

Btw. on a personal note: understanding why we need to discourage those. 
Do we need to judge the security of hash algorithms in every standards 
documents using them individually? After all, after a couple of years 
even SHA-3 may become weak/broken while the RFC would still encourage 
one alg and discourage the others. Don't we have a central place to 
state quality/recommendation of used algorithms, that could just be 
referenced to enhance alg agility.

---

From: [email-masked]
Date: Thu, 29 Sep 2011 23:00:40 +0100 (IST)

<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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Sep 2011 21:55:07 -0400

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?

---

From: [email-masked]
Date: Fri, 30 Sep 2011 15:40:10 +0100 (IST)

Hiya,

> the ODI thing in CAA v1.0?

Could be. When my little brain sees a good idea, it tends to repeat
it:-)

> we end up with having one, not three.

Strongly agree. I think a URI for naming things with digests should
have broad applicability.

> includes URL like things.

Yep. We have use-cases for that. Note though that the authority
part is optional, so a fairly bare digest is quite possible and
would look like ni:///sha256:NDVmZTMzOGVkY2Jj...

> a resolvable format. I have to go look at the URN and URI specs again

I also thought about URNs but was told (by PSA I think) that those
are intended for managed name spaces and not things like this.

> for obvious security reasons.

Our use-case for that is for cases where the named object actually
arrives in some wrapped form (e.g. encrypted) and you need to know
the "inner" content type. However, I could see it being used otherwise
or being dropped as things progress.

> the proposal and come back?

I'm not bothered by where or how we progress this, so long as we do
the right thing and do it once:-)

I need to check with co-authors about what DECADE want, but this I-D
could be worked there or here in WEBSEC. I'm very happy to have more
help as well if it gets us closer to doing this once only.

FWIW, we're part of a project that is coding this up, and will
almost certainly release a library with a reasonable license in a
few months.

Cheers,
S.