W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2017

Re: Proposal: Signatures in SRI.

From: Adam Langley <agl@google.com>
Date: Thu, 1 Jun 2017 11:54:05 -0700
Message-ID: <CAL9PXLzuptni1SZeM0BEF7koKrxArMaq9=Ut2r5NWgYsWNOg8A@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Devdatta Akhawe <dev.akhawe@gmail.com>, freddyb@mozilla.com, Francois Marier <francois@mozilla.com>, joel.weinberger@gmail.com, Brad Hill <hillbrad@gmail.com>, Ryan Sleevi <sleevi@google.com>
On Thu, Jun 1, 2017 at 3:18 AM, Mike West <mkwst@google.com> wrote:

> https://tools.ietf.org/html/draft-thomson-http-mice, is, I think, the
> link you were looking for.
>
>
>> That also suggests an enhancement for integrity more generally.
>>
>
> I think it's a reasonable one, pretty much in line with what agl@ was
> proposing a million years ago. We never ran with his proposal because folks
> were concentrating on scripts and style (which are processed atomicly), and
> the complexity of streaming was hard to justify.
>

Yep. An unbalanced Merkle tree is the only reasonable solution that I'm
aware of. An open question is whether the hashes should be distributed
throughout the file (as I think I prefer, and Martin proposes) or served
all at the beginning in an HTTP header. The latter allows the same resource
on disk to be used for fetches both with, and without integrity, but is a
bit shitty.

On your work:
>> One major limitation of using ed25519 is that you can't incrementally
>> calculate the signature; you should at a minimum consider the
>> pre-hashed variant if you intend for this to be universally
>> applicable.  The draft above would be trivial to get to work with
>> ed25519.
>>
>
> I don't know enough in this space to have an informed opinion about the
> options. CCing agl@. :)
>

The current SRI assumes that resources are small and not incrementally
parsed, so ed25519 fits nicely. Combining ed25519 with an unbalanced Merkle
tree effectively does make it the pre-hashed version, so that's fine too.
So, if SRI sticks to it's current goal of only covering small resources,
ed25519 seems applicable. If it wants to cover large resources, support for
Merkle trees is needed and then we effectively have ed25519ph already, or
we can actually use ed25519ph on the basis that we're already there and why
hash the first record twice?


Cheers

AGL
Received on Thursday, 1 June 2017 18:54:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:23 UTC