Re: Signed and indexed packaging proposal.

On Fri, Nov 18, 2016 at 1:54 PM, Dmitry Titov <dimich@google.com> wrote:
> Sorry for broken links, github decided to block the repository, i pinged
> their customer support, it looks working now:
> https://github.com/dimich-g/webpackage/blob/master/README.md

It seems like this is going to run afoul of a range of issues:

1. certificate keys are generally only used for signing TLS handshake
transcripts, this new usage would create a new usage model for those
keys that would need to avoid cross-domain signature reuse attacks

2. certificate validation in this context does not benefit from the
multitude of features provided by TLS, including things like OCSP
stapling (or online revocation checking, but no one does that).

3. similar to above, how are certificates acquired?

4. what if certificates expire?

5. the content is obviously a snapshot in time, which implies that the
entity constructing the package would need to be responsible for
ensuring consistency; however, this might interact poorly with caching
of those resources if there are newer versions in the browser cache.
Given that these are likely not fresh in the HTTP caching sense, the
browser will need special overrides for freshness checks on certain
resources.

6. if these resources overwrite entries, then the cache could be
polluted by old content, which might be exploited by an attacker

There are probably a bunch of other considerations here; my brain is a
mushy soup from a long IETF week.  The signature (if it can be made to
work) would obviously help avoid some of the previous complaints that
the packaging stuff attracted, but as you can see, it comes with a
bunch of new work, some of that work being non-trivial.

(And now I have to board a plane.)

Received on Friday, 18 November 2016 10:23:09 UTC