Re: Origin-signed responses

[Ilari Liusvaara <[e-mail]>]

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-responses-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).

- 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.

  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).

- The main risk in just using server PKI keys is server accidentially
  signing a valid response. 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.

  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).

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

- 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.


-Ilari