Re: Origin-signed responses

Thanks for the comments! I have updates for this in
https://github.com/WICG/webpackage/pull/84, and responses inline below.

On Sat, Sep 2, 2017 at 8:32 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Fri, Sep 01, 2017 at 09:35:27AM -0700, Jeffrey Yasskin wrote:
> > Hi all,
> >
> > When I brought web packaging to IETF99 DISPATCH
> > (https://datatracker.ietf.org/doc/minutes-99-dispatch/), several
> > people said they wanted to see what it would look like split into
> > layers. https://tools.ietf.org/id/draft-yasskin-http-origin-signed-r
> esponses-00.html
> > discusses use cases and an outline of what the signing layer needs to
> > look like, but doesn't include an actual proposal for signatures yet.
> >
> > What do you think? Is splitting the packaging proposal still the right
> approach?
>
> Some random comments (in no practicular order nor connection):



> - The main problem seems to be freshness: How to ensure that the signed
>   responses are not stale (this appears to be connected to the HTTP
>   caching model).
>

Indeed.

- Regarding Extended Key Usage: I do not think EKU would be good for
>   use-case like this even if it was decided that one needed to flag
>   certificates for this kind of usage.
>
>   The reason is that while by specification EKU only appiles to usage
>   of the certificate itself, de-facto interpretation (which browsers
>   actually rely on security!) is that EKU is inherited down the
>   chain. Thus to add a new EKU to end-entity certificates, it may be
>   necressary to re-issue intermediates, which is quite lengthy process
>   for a reason.
>

Good point. I'll add this to the reasons to avoid an EKU.

  Having a certificate extension would be another possibility, however
>   that also has its problems (will likely take quite long time to be
>   available and is of questionable benefit, because either the
>   certificate does not actually need it, or it can be used in dangerous
>   ways anyway).
>

Thanks for pointing that out. I'll add it as a possibility for
completeness, but I do still prefer just allowing a server PKI key.

- The main risk in just using server PKI keys is server accidentially
>   signing a valid response.


The second risk is that server PKI keys have to be stored online, so
they're easier to steal than an offline key, and that's an unnecessary risk
for packages which could be signed with an offline key.


> Such accidential signatures can come from
>   two sources:
>
>   1) Confusion with some other type of key exchange.
>   2) Confusion with some other type of signature.
>
>   The first is mainly risk for OID 1.2.840.113549.1.1.1 generic RSA
>   keys, as due to server misconfiguration, those can be used with
>   various broken key exchanges that may be exploitable to create valid
>   signatures. Other key algorithms, like 1.2.840.113549.1.1.10
>   (RSA-PSS), 1.2.840.10045.2.1 (generic ECC), 1.3.101.112 (Ed25519)
>   and 1.3.101.113 (Ed448) are not affected, or are affected much less.
>

Thanks. It sounds like I need to restrict the kinds of keys that are
allowed to be used for these signatures instead of allowing the key from
any trusted certificate. I think I forgot to say it in the draft, but I'm
also expecting to identify exactly one signing algorithm for each key type,
instead of letting attackers specify the algorithm.

  According to spec, the KeyUsage could be used to disable the
>   problematic uses without affecting non-problematic ones.
>   Unfortunately, in practice KeyUsage is not implemented correctly
>   enough to serve in that role.
>
>   The second is mitigated fairly well by using the TLS 1.3 signature
>   construction with custom label/context, as pointed out in section
>   4.1 (Proof of Origin).
>
> - Be careful with passing URLs to certificates. There are at least two
>   kinds of pitfalls here:
>
>   1) One needs to hash or MAC the certificate to avoid attacks.
>   2) The URL could point to some rather sensitive place (for probing or
>      exploiting bad GET handling).
>

I don't follow this, sorry.

1) You're saying that if the attacker gets to specify their own
certificate, they can a) attack the verifying software or b) cause their
own package to be accepted for the origin?
2) Is this more sensitive than an attacker's page being able to write an
<img src=https://sensitive.info/>? I don't really see how. I can imagine
that we'll need a failed certificate fetch to have the same result as a
successfully-fetched but untrusted certificate.

- On stapling things to certificates, there is presumably also stapling
>   Certificate Transparency SCTs (and also STHs for interactive
>   clients).
>

Yeah ... I'd expected folks would be including SCTs into the certificates
themselves, but I see they can also be transmitted through TLS or OCSP
extensions: https://tools.ietf.org/html/rfc6962#section-3.3. Would it be
sensible for this draft to require the SCTs to be embedded in the
certificate or OCSP, or do we need to allow them to appear separately too?

- If application/http2 type format is used, it obviously can not use
>   the main header compression state. Less obviously, it does not seem
>   like it can use any header compression state, and thus, each pair of
>   sets of headers (request-response pair) needs to be compressed
>   independently.
>

Yes. I've been talking to the Brotli folks about sharing compression state
across bundled sets of requests, but for a single request, it has to be a
pristine state for each one.

Thanks,
Jeffrey