Re: Hashes.

On Wed, Dec 11, 2013 at 3:04 AM, Mike West <mkwst@google.com> wrote:
>
> I've taken a stab at wrapping up the various threads on script hashes into some spec text that I hope addresses most concerns, and just added [1], [2], and [3] to the spec for discussion.
>
> In particular:
>
> 0. I think we want both hashes and nonces. The spec reflects that.
>
> 1. I'm deferring to the HTML spec for the definition of the script block's source, which I think gives us good chances of both understanding how the script block is parsed and understood, and interoperating on that understanding. Adam, your input would be particularly valued here: is that definition enough, or do we need to more explicitly talk about encodings and canonicalization?
>
> 2. 'unsafe-inline' is disabled if either a hash or nonce is present.
>
> 3. I'm running with Garrett's suggestion that we support only SHA-2 algorithms. I think there's value in supporting SHA-1 (number of bits on the wire, if nothing else), and I'd like to add it in. Moreover, there might be value in writing the spec such that future algorithms can be supported if browser vendors choose. I'm not sure we need to be explicit about the supported algorithms (other than to specify something like SHA-256 as mandatory to support, to ensure we have a common baseline). Opinions welcome. :)

Thanks for this patch, it's nice to see this moving forward.

>
>
> [1]: https://dvcs.w3.org/hg/content-security-policy/rev/20f1d3204a37


The change of "nonce-value" to "base64-value" is undesired for the
following reasons:

(a) When using a nonce in scripts or styles, the nonce-value is not
the base64 encoding of anything. It's just a random string securely
generated by the server independently for each request. The spec
grammar should use a name that reflects this. "nonce-value" is
appropriate, but "base64-value" is not.

(b) The grammar key "nonce-value" is referenced 3 times in the rest of
the spec. This change makes these references dangling. Furthermore,
changing these references to "base64-value" to match the grammar is
not a good idea, as they talk about the semantics of nonce-value in
particular. The references are in sections 3.2.2.3 and 3.2.2 and the
text talks particularly about the nonce, not the hash.

I recommend we go back to "nonce-value" as a separate grammar record
for the nonce value, and use an identical grammar record with the same
right-hand-side called "hash-value" for the hash value.

>
> [2]: https://dvcs.w3.org/hg/content-security-policy/rev/053e1cf7c388

The NIST standard illustrates hash results as hex. We want to make it
clear that the binary result of the hashing functions is subsequently
fed to base64. Let's add a clarification there.

Recommend that we change the following:

If the <a href="#dfn-digest-of-an-elements-contents"><var>algorithm</var>
digest of <var>element</var>'s contents</a> is a case-insensitive match for
<var>expected</var>, return true and abort these steps.

To the following:

If the <a href="http://tools.ietf.org/html/rfc4648#section-4">base64
encoding</a> of
the binary <a href="#dfn-digest-of-an-elements-contents"><var>algorithm</var>
digest
of <var>element</var>'s contents</a> is a case-insensitive match for
<var>expected</var>, return true and abort these steps.

Even better, it would be great to define a separate "actual" in
addition to "expected".

Recommend that we also add something along the lines of the following,
to ease adoption and implementation for web developers:

If the user agent fails to match hash-value, the user agent SHOULD
report a warning message in the developer console containing the
actual hash value.

These modifications are reflected in the attached patch
(csp-specification.dev.html.patch).

Thanks!

> [3]: https://dvcs.w3.org/hg/content-security-policy/rev/8db37e53da82
>
> Thanks (and apologies for the delay/my absence; I've been buried in non-CSP work recently)!
>
> --
> Mike West <mkwst@google.com>
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)