Subject: [decade] Updated Digest Scheme URI

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Oct 2011 16:40:56 -0400

I have made major modifications to the digest scheme from the first version:

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

The main changes relevant to the initial WebSEC use cases are:

* Identifiers are now text strings using the IANA crypto algs registry
* A 'start' has been made on getting the URI template filled in
* The encoding scheme base64url encoding is used to comply with URI requirements
* The content type is specified as a parameter

In addition the following features have been outlined to demonstrate
that it is possible to create a digest URI that WebSec and DECADE
could both use:

* Optional parameters section
* Scheme for specifying one or more locations for retrieval
* Scheme for decrypting encrypted stored content.

Note that these particular use cases actually address recurring WEBSEC
type issues, namely how to securely reference content stored on an
untrusted server. Simply saying 'SSL' does not in fact solve this
question since the linked content may be in a different trust zone.
this turns up all the time with 'rickrolling' and general Slashdot
fun.

The main difference between my approach and Stephen's is that Stephen
puts the domain portion first as is traditional for a URL. I throw it
in as a parameter. Why? Well for static data (as we are doping here)
the digest is a far more permanent and specific identifier of the
content than one location that might return the data. So it really
makes sense to put that up front and make it the first thing in the
digest.

Some form of URL transformation is going to be required in either
scheme. As has been discussed on the list, relativity really does not
provide much leverage here.

The big payoff in my mind for DECADE is that this makes specifying
more than one download location easy as well. It also makes it easy
for aware applications to add and subtract locations as is sensible.
If content is deposited in a cache, the cache can add its domain into
the URI scheme.

So the simplest URI described in the paper is:
di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc

The simplest secure reference is:
di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?ct=text/plain

Addressing DECADE type use cases:

A reference can be specified to external content:
di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?http=di.example.com

This maps to the following URL:
http://di.example.com/.well-known/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc

And the scheme can be extended to cover encrypted content as well:
di:sha-128:B_K97zTtFuOhug27fke4_Q?enc=aes-cbc:Fw3x20nEKfq6FDGzq7ttIQ

Have to credit Rohit Khare's work here as we both played around with
this stuff back in 1995 when we were working for the Web Consortium.

Note that the parameter schemes are proposed as illustration, not as
something that I insist on. The point I want to make here is purely
about the extensibility of the format proposed. If people want to only
consider the WEBSEC use cases in that WG and ignore DECADE, then we
could strip them out for the base draft and then have a supplemental
draft that describes the extra features.

My view is that the locator hints are actually very useful in the
WEBSEC cert pinning context as they allow means for downloading the
related certs.

The encryption stuff is likely very interesting in DECADE as it means
that the identifier is essentially a self contained capability for the
referenced content.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Oct 2011 22:53:53 -0400

Ooops, that was an oversight in the draft, sorry.

I did actually go so far as to specify the allocation of a di
.well-known code point, I just forgot to use it!

The URL was meant to be:

https://di.example.com/.well-known/di/sha-256/B_K97zTtFuOhug...

Sorry for the confusion.

On Mon, Oct 3, 2011 at 10:02 PM, Thomson, Martin
<[email-masked]> wrote:
> On 2011-10-04 at 07:40:56, Phillip Hallam-Baker wrote:
> ...
> Please don't use /.well-known/ without some sort of extra qualification.  My "mu" digest produces base-64 output that could collide with existing registrations in that space.  It's just like a game of "battleship".  I'm really hoping to hit "host-meta" some day...
>
> What do you think of:
>
>  di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?r=https://di.example.com/r/
> or
>  di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?r=https://di.example.com/r/{d}
>
> ...where retrieval is performed using:

If we went this route I can't see why the digest would appear anywhere
other than the end so why not just specify it as a prefix?

The slippery slope there would be people looking to take parts of the
digest and the algorithm in mix 'n match type approaches.

Since this is a domain specified in a fairly tightly controlled URL, I
don't see why collisions with other services can't be handled by
people creating a new sub-domain specially for di content if required.

I am not completely happy with .well-known, it is a yucky approach,
but it is now sufficiently well established that it is probably OK.

> I don't see the encryption and content type parameters as a necessity.  If the core goal of the document is to identify a resource, then providing resource metadata is, as a generic capability, very useful.  However, the specific subset of cases you have chosen exhibits a bias that might not fit with all future uses.
>

True in the case of encryption, but I prefer to do stuff once if
possible. The fact that there are parameters and the space is
extensible means that there is room for other uses.

The content type is essential meta-data if the digest is going to be
used to create a strong reference to the specified content. Otherwise
the attacker can repurpose an image/jpeg as application/script. This
works much better than it should because most processors simply ignore
content they don't understand and helpfully try to resynchronize.

This creates attacks where the attacker can smuggle his malware into a
photosharing site and then get links to it. It would create a new
class of cross-site scripting attack if it was not present.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Oct 2011 07:56:14 -0400

On Mon, Oct 3, 2011 at 11:22 PM, Manger, James H
<[email-masked]> wrote:
> Instead if defining new names for truncated digests, why not simply include a truncated digest with the existing algorithm name? You can determine the truncation (in bytes) from the length of the base64url-encoding so there is no ambiguity.
>
>  di:sha-256:B_K97zTtFuOhug27fke4_Q
>
> The only downside I see is the risk of bad implementations accepting a digest truncated to, say, 1 byte (eg di:sha-256:Bw) instead of enforcing a minimum security level.

That is a risk that has been realized for HMACs in certain circumstances.

A caveat is probably sufficient.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Oct 2011 08:07:17 -0400

On Tue, Oct 4, 2011 at 12:46 AM, Thomson, Martin
<[email-masked]> wrote:
> On 2011-10-04 at 13:53:53, Phillip Hallam-Baker wrote:

> You aren't making the world a less safe place if you leave the problem alone.  Or have I missed something.  What makes this scheme any worse for the attack, other than its inherent opacity?

The use case there is creating a strong reference from a https page to
a plain http one. In that case there is an issue.

It is a real attack and an increasingly serious one.

But the issue is moot since DECADE requires the ability to select
between locators so that it gets one with a content type it has a
codec for.

> Regarding de/encryption keys: Is it really the case that you need to decrypt before calculating the digest?  Excuse my ignorance, but for a file store, I would have thought that encryption would want to come before storage.

There are pros and cons for the order of operations wrt encryption and
authentication. The ideal is actually authenticate (encrypt (content +
authenticate (content)))

For our application I think it is pretty clear that the digest would
need to be of the plaintext. I don't like revealing any info on the
plaintext.

I will correct that.