Subject: Origin-signed responses

From: Jeffrey Yasskin <[email-masked]>
Date: Fri, 1 Sep 2017 09:35:27 -0700

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?

I've also started a thread in art@ to talk about the packaging use
cases overall: https://mailarchive.ietf.org/arch/msg/art/gaS8EHxsdzcyPCaSqSyWSh-WbMY

Thanks,
Jeffrey

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 1 Sep 2017 17:04:02 +0000

Hi Jeffrey,

I spotted this yesterday and found it an interesting read, so thanks for starting a discussion.

Your draft references draft-cavage-http-signatures, which we have been using on a project to add some authenticity to HTTP/2 pushed content. I'm still processing your draft but can see how it might complement our approach or help satisfy the higher goal.

Meanwhile, web packaging is beyond the scope of my needs.

Therefore I support the split because it's provides a more compelling document to consider, in my particular use case.

Kind regards
Lucas
________________________________________
From: Jeffrey Yasskin [[email-masked]]
Sent: 01 September 2017 17:35
To: HTTP Working Group
Subject: Origin-signed responses

Hi all,

Thanks,
Jeffrey

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: Jeffrey Yasskin <[email-masked]>
Date: Fri, 1 Sep 2017 10:18:01 -0700

> Your draft references draft-cavage-http-signatures, which we have been using on a project to add some authenticity to HTTP/2 pushed content. I'm still processing your draft but can see how it might…

I'm glad to hear it. :) What kind of software winds up checking that
authenticity? How do you transmit the public key? Do you need to
revoke keys or prevent downgrade attacks? (I'd be happy to read a
document about this, if you have one, rather than making you retype it
on the mailing list.)

Thanks,
Jeffrey

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 1 Sep 2017 17:36:33 +0000

We've written up some of it in the I-D draft-pardue-quic-http-mcast. Section 6 and appendix B are particularly relevant. 

We expect the checks to happen in the application code, running in or above a HTTP UA of some sort. E.g. an app that incorporates libcurl, or JavaScript application code executing in a browser.

Lucas
________________________________________
From: Jeffrey Yasskin [[email-masked]]
Sent: 01 September 2017 18:18
To: Lucas Pardue
Cc: HTTP Working Group
Subject: Re: Origin-signed responses

Thanks,
Jeffrey

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 2 Sep 2017 18:32:53 +0300

> 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

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 6 Sep 2017 11:47:22 -0700

Thanks. In draft-pardue-quic-http-mcast-01 you do have enough of a channel
in the Alt-Svc header to transmit a signing key, so you could use
draft-cavage-http-signatures, but the spec and examples show the public key
being identified alongside the signature, which isn't enough to establish
that the expected sender is actually the one that signed the message.

draft-yasskin-http-origin-signed-responses would be harder to use
incorrectly inside higher-level protocols, since it insists that the key is
trusted for the example.com domain.

Jeffrey

On Fri, Sep 1, 2017 at 10:36 AM, Lucas Pardue <[email-masked]>
wrote:

> We've written up some of it in the I-D draft-pardue-quic-http-mcast.
> Section 6 and appendix B are particularly relevant.
>
> We expect the checks to happen in the application code, running in or
> above a HTTP UA of some sort. E.g. an app that incorporates libcurl, or
> JavaScript application code executing in a browser.
>
> Lucas
> > Your draft references draft-cavage-http-signatures, which we have been
> using on a project to add some authenticity to HTTP/2 pushed content. I'm
> still processing your draft but can see how it might complement our
> approach or help satisfy the higher goal.
> >
>

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 6 Sep 2017 11:48:49 -0700

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

>   responses are not stale (this appears to be connected to the HTTP

Indeed.

>   necressary to re-issue intermediates, which is quite lengthy process

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

>   certificate does not actually need it, or it can be used in dangerous

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.

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

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.

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

>   Certificate Transparency SCTs (and also STHs for interactive

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?

>   sets of headers (request-response pair) needs to be compressed

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 6 Sep 2017 22:30:10 +0300

> for packages which could be signed with an offline key.

Oh yeah, there is no technical reason to require signatures to be with
the same certificates the server uses.
 
> instead of letting attackers specify the algorithm.

These attacks against generic RSA keys aren't actually confusing
signature algorithm with another signature algorithm, but exploiting
non-signature algorithms to forge signatures.

There were some key type confusion attacks against generic ECC keys too
(there is apparently no "ECDSA" key type), but IIRC those did not allow
forging signatures, unlike the attacks on generic RSA keys.

I have seen some papers about confusions between signature algorithms,
but those are seemingly about exploiting weak hash algorithms or
trivial collisions.

> own package to be accepted for the origin?

Well, being able to replace the certificate with different one with the
same key in key exchange is regarded to break the key exchange
security.

Such certificate replacement is especially bad if client trusts other
attributes besides the key and the domain names.

TLS does have extension for sending the client certificate as URL. That
extension does carry SHA-1 (yeah, I know) hash of the certificate in
order to defend against certificate substitution.

> successfully-fetched but untrusted certificate.

Not really. I meant more references to resources that are not available
in globally routed addresses (especially local LAN addresses).

Requiring CORS preflights for external chains would likely take care of
most of it.

> certificate or OCSP, or do we need to allow them to appear separately too?

The base certificate transprancy has three transport modes, and the
specification requires clients to support all three:

- Stapled in certificate.
- Stapled in OCSP.
- Dedicated TLS extension.

The last is especially significant if the CA does not actually support
CT. And stapling to certificate is technically more difficult to
implement than stapling to OCSP (if webservers actually properly
supported OCSP stapling, I would think that CAs would much rather
staple CT to OCSP than certificates... If they did the stapling at
all.)

-Ilari

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 6 Sep 2017 19:51:57 +0000

Hi Jeffrey,

You make a good observation. draft-pardue-quic-http-mcast-01 skips some details, we have an implementation that does some additional things that aren't explain anywhere (yet). Since this is Alt-Svc, we try to follow those security expectations in our implementation, to form a bit of a closed loop. The sender's signature keyID is in the form of a certificate that is valid for the sender's source IP and the origin.

Is that similar to draft-yasskin-http-origin-signed-responses?

draft-cavage-http-signatures leaves the usage of KeyId open, so looking ahead we'd have to profile or mandate our approach. If your proposal is stricter, that could help simplify things for us in terms of documentation and getting wider adoption/support.

Lucas
________________________________
From: Jeffrey Yasskin [[email-masked]]
Sent: 06 September 2017 19:47
To: Lucas Pardue
Cc: HTTP Working Group
Subject: Re: Origin-signed responses

Thanks. In draft-pardue-quic-http-mcast-01 you do have enough of a channel in the Alt-Svc header to transmit a signing key, so you could use draft-cavage-http-signatures, but the spec and examples show the public key being identified alongside the signature, which isn't enough to establish that the expected sender is actually the one that signed the message.

draft-yasskin-http-origin-signed-responses would be harder to use incorrectly inside higher-level protocols, since it insists that the key is trusted for the example.com<http://example.com> domain.

Jeffrey

On Fri, Sep 1, 2017 at 10:36 AM, Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:
We've written up some of it in the I-D draft-pardue-quic-http-mcast. Section 6 and appendix B are particularly relevant.

Lucas
________________________________________
From: Jeffrey Yasskin [[email-masked]<mailto:[email-masked]>]
Sent: 01 September 2017 18:18
To: Lucas Pardue
Cc: HTTP Working Group
Subject: Re: Origin-signed responses

Thanks,
Jeffrey

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 6 Sep 2017 17:20:56 -0700

draft-yasskin-http-origin-signed-responses does plan to require that the
certificate is trusted for the sender's origin. My proposal doesn't require
the certificate to include the sender's source IP, so if you need that in
addition to the origin, you'd wind up profiling mine too.

On Wed, Sep 6, 2017 at 12:51 PM, Lucas Pardue <[email-masked]>
wrote:

> Hi Jeffrey,
>
> You make a good observation. draft-pardue-quic-http-mcast-01 skips some
> details, we have an implementation that does some additional things that
> aren't explain anywhere (yet). Since this is Alt-Svc, we try to follow
> those security expectations in our implementation, to form a bit of a
> closed loop. The sender's signature keyID is in the form of a certificate
> that is valid for the sender's source IP and the origin.
>
> draft-cavage-http-signatures leaves the usage of KeyId open, so looking
> ahead we'd have to profile or mandate our approach. If your proposal is
> stricter, that could help simplify things for us in terms of documentation
> and getting wider adoption/support.
>
> Lucas
> ------------------------------
> *From:* Jeffrey Yasskin [[email-masked]]
> *Sent:* 06 September 2017 19:47
>
> *To:* Lucas Pardue
> *Cc:* HTTP Working Group
> *Subject:* Re: Origin-signed responses
>
> Thanks. In draft-pardue-quic-http-mcast-01 you do have enough of a
> channel in the Alt-Svc header to transmit a signing key, so you could use

---

From: Jeffrey Yasskin <[email-masked]>
Date: Thu, 7 Sep 2017 10:24:35 -0700

> non-signature algorithms to forge signatures.

Ah, got it. I've refined that note in my draft.

> order to defend against certificate substitution.

That's an odd threat, but sure, it looks straightforward to include the
certificate chain in the signed bytes, like TLS does (
https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.4.3).

> Requiring CORS preflights for external chains would likely take care of

An <img> tag can also refer to resources that aren't available in
globally-routed addresses, and we only require CORS for those if the page
wants to read the content of the image. Since we're not letting the
attacker (author of the "signed" response) read the content of the
certificate, just use it to validate the signature, I don't yet see the
need for CORS. What's the attack here?

I think the attacks along these lines in
https://tools.ietf.org/html/rfc6066#section-11.3 don't apply, since an
attacker who can get a client to download a package and then retrieve
certificates referenced from it, can also get the client to perform the
same fetches in other ways.

> staple CT to OCSP than certificates... If they did the stapling at

I'm not sure it's worth supporting the use case of a CA that doesn't
support CT, since Chrome's going to require them all to support CT in 7
months (
https://groups.google.com/a/chromium.org/d/topic/ct-policy/sz_3W_xKBNY/discussion).
That said, if we staple OCSP responses using the TLS CertificateEntry
format, SCTs fit in exactly the same place.

Jeffrey

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 10 Sep 2017 15:46:10 +0300

> https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.4.3).

Yes, it is odd, but considering key exchange vulernable to similar
issue is considered broken...

> same fetches in other ways.

I think there are proposals to require (special) CORS for all requests
to local scope (LAN, localhost) from global scope.

> format, SCTs fit in exactly the same place.

AFAIK, Chrome will accept staples via dedicated TLS extension, which
does not need CA support.

And to extend the argument, if webservers actually properly supported
CT stapling, there would probably be CAs that did not do anything with
CT, even after Chrome switching to require CT for all new certs.

-Ilari