Subject: Origin Signed Responses and certificate requirements

From: Yoav Weiss <[email-masked]>
Date: Mon, 09 Apr 2018 11:54:26 +0000

Hey all,

While reviewing the Origin Signed Responses draft, I noticed that the
certificate
requirements
<https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#cross-origin-cert-req>
section
requires the signing certificate to have a specific opt-in to response
signing while also prohibiting such certs from serving TLS connections.

>From a deployment perspective, the second requirement means that an entity
which wants to sign packages as well as terminate TLS connections would
have to maintain multiple certs for each domain, which will significantly
increase complexity.

I'm wondering regarding the reasoning behind that second requirement. Why
can't certs which opt-in to signing packages also be able to serve TLS?
What are the risks involved?

Thanks,
Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 9 Apr 2018 15:14:14 +0300

> What are the risks involved?

Specifically, this is because RsaEncryption keys can be used with
insecure static RSA key exchange that will yield a signing oracle
if one gets it even slightly wrong. And such oracles would be very
bad thing in context like this.

In theory, this would not be needed for RSA-PSS, ECC or EdDSA
keys. But this requirement appiles even to them in name of
consistency.

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 9 Apr 2018 10:47:32 -0400

On Mon, Apr 9, 2018 at 8:14 AM, Ilari Liusvaara <[email-masked]>
wrote:

> > <https://wicg.github.io/webpackage/draft-yasskin-http-
> origin-signed-responses.html#cross-origin-cert-req>
> > section

Ilari is spot-on.

One further note to add: This is also about the difference between the
server's expected/desired security properties and the client's
expected/desired security properties. That is, a server may be fully
cognizant of the risk that a signing oracle poses and take steps to
mitigate, and thus may argue that they should be able to use a single
certificate for both cases. And while they may do so successfully, the
client has no way of distinguishing between a server that is cognizant -
and has taken steps to mitigate - and a server that is not cognizant, and
thus risky. Thus the proposed protocol-level separation of these concerns.

To some extent, these concerns are also relevant to the CERTIFICATE frame -
whether or not the tradeoff in security property necessitates some form of
opt-in by the server (to indicate awareness of the issues - such as key
compromise), and whether there needs to be a protocol layer separation for
clients to ensure that. Of course, alternative solutions may and likely do
exist for the CERTIFICATE frame, given the online nature of the exchange.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 9 Apr 2018 18:07:42 +0300

> exist for the CERTIFICATE frame, given the online nature of the exchange.

The CERTIFICATE frame does have secure nonce, but due to much longer
attack window than with exchange signatures, perhaps oracle attacks
could be practical.

Another place that has some real concenrs with oracles is sub-
certificates proposal (which is a WG document).

-Ilari

---

From: Jeffrey Yasskin <[email-masked]>
Date: Mon, 09 Apr 2018 17:00:28 +0000

On Mon, Apr 9, 2018 at 5:14 AM Ilari Liusvaara <[email-masked]>
wrote:

> > <
> https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#cross-origin-cert-req
> >
> > section

Because we've switched to requiring new certificates, I've been toying with
the idea of being much stricter with the set of allowed certificate types.
Do y'all think it'd be a good idea to require that everyone using v1 of
signed exchanges use exactly one kind of certificate, say secp256r1 ECDSA?
And if we did that, could we allow them to re-use that certificate for
their TLS servers?

Jeffrey

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 9 Apr 2018 20:25:53 +0300

> And if we did that, could we allow them to re-use that certificate for

I do not like that very much...

One slightly less bad one would be require certificate that is
considered ECDSA-type (TLS_ECDHE_ECDSA_WITH_*) in TLS 1.2 (which
includes EdDSA certificates). Of course, that would be somewhat
complicated rule.

-Ilari

---

From: Jeffrey Yasskin <[email-masked]>
Date: Mon, 09 Apr 2018 18:25:03 +0000

On Mon, Apr 9, 2018 at 10:26 AM Ilari Liusvaara <[email-masked]>
wrote:

> > On Mon, Apr 9, 2018 at 5:14 AM Ilari Liusvaara <[email-masked]
> >
> > wrote:
> >

Thanks. Could you say a little more about why? Which specific other
certificate types do you want to be able to use before we use a v2 to
revise the cryptographic suite? Are you looking for ed25519 support, keys
with a security level higher than 128 bits, the ability to add post-quantum
algorithms, or something else?

> includes EdDSA certificates). Of course, that would be somewhat

Or a certificate usable with "a non-legacy, non-RSA signature algorithm
accepted by TLS 1.3", which today would be ecdsa_secp256r1_sha256,
ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, ed25519, or ed448? Or is
there a TLS 1.2 algorithm you definitely want to use?

It sounds like you might be fine with using a non-RSA certificate as both a
TLS server certificate and package-signing certificate?

Jeffrey

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 9 Apr 2018 21:34:00 +0300

> algorithms, or something else?

Pretty much that.

> there a TLS 1.2 algorithm you definitely want to use?

Well, that is pretty much the same set of certificates as used by
TLS_ECDHE_ECDSA_WITH_* in TLS 1.2.
 
> TLS server certificate and package-signing certificate?

Yeah, I consider RSA pretty much legacy.

-Ilari

---

From: Jeffrey Yasskin <[email-masked]>
Date: Thu, 12 Apr 2018 00:33:56 +0000

On Mon, Apr 9, 2018 at 11:34 AM Ilari Liusvaara <[email-masked]>
wrote:

> > > > Because we've switched to requiring new certificates, I've been
> toying
> > > with

Thanks. I have a PR implementing this at
https://github.com/WICG/webpackage/pull/179, which I'd love folks to review.

Jeffrey

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 12 Apr 2018 09:36:30 -0400

I commented on the PR, but in the spirit of bringing things to the list, I
think allowing reuse with TLS is a net-negative for security, and we should
not do this.

The same conversation being had around Secondary Certificates and Delegated
Credentials is applicable here. In this case, we have an online signing
entity that fundamentally must be near the edge (to terminate TLS), while
also granting it the ability to create long-lived signatures (the web
package). From an operational standpoint, this incentivizes weak key
protection, when the threat model of Web Packaging arguably requires
stronger key protection, due to the greater risk being introduced to
clients - namely, the ability to deploy misused signatures more widely
(from oracles or key compromise).

Just as in the Secondary Certificates discussion, in which key separation
or the enforced-use of Delegated Credentials (which permits, but does not
guarantee, a degree of key separation and protection), I think in the Web
Packaging case, the likely actual deployment of servers, and the security
risks to clients, is a reasonable reason to ensure the protocol-level
separation. Beyond the key protection mechanism, the differences in
signatures here ensures a reduction of risk from cross-protocol confusion
and attacks - something that was previously intentionally mitigated by
enforcing this separation.

So no, I don't believe allowing reuse is good. And while some providers may
do operationally idiotic things (such as reusing the keys between the
different certificates), the ecosystem does not incentivize or encourage
that.

On Wed, Apr 11, 2018 at 8:33 PM, Jeffrey Yasskin <[email-masked]>
wrote:

> Thanks. I have a PR implementing this at https://github.com/WICG/
> webpackage/pull/179, which I'd love folks to review.
>
> Jeffrey
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 12 Apr 2018 20:51:13 +0300

> (from oracles or key compromise).

Web packaging is not similar to Secondary Certificates. It is however
similar to Delegated Credentials.

Both Web Packaging and and Delegated Credentials:

- Are insecure against weak compromise. So ROBOT/DROWN type attacks
  would be devastating.
- Can have the key (semi-)offline.

However, Secondary Certificates:

- Are secure against weak compromise (but not full compromise).
- Must have the key online.
- More vulernable to ROBOT/DROWN type attacks than TLS handshakes due
  to longer time windows.

Also, saying that keys for for WP/DC SHALL be protected in some
specified way would have really nasty interactions with current
CABForum BRs, making it effectively impossible to get such
certificates. So any enhanced protection is at most RECOMMENDED.

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 12 Apr 2018 14:09:00 -0400

> similar to Delegated Credentials.

Sure it is. A compromise of a secondary certificate key, or of a web
packaging key, reduces the cost of attack to "Can I induce a client to talk
to the attacker" - which, in a Web context, is sort of a key design feature
of the Web. If you can, then the holder of a compromised Secondary
Certificate, or a compromised Signed Exchanges key, can induce a client to
accept as "from the origin" their content, in an otherwise undetectable
manner.

> certificates. So any enhanced protection is at most RECOMMENDED.

I'm not sure why you say they would have 'really nasty interactions'.
Parties that want code signing certificates from CAs trusted by Microsoft,
for example, can only do so for keys on hardware security modules. Which
effectively means the CA sending out an USB token or smart card, and
provisioning the key themselves.

I agree that, in terms of the status quo, this is an increase over the
requirements to obtain a web server certificate. But it's something we at
least need to consider as "an option", when considering the interactions
between the security assumptions being made by clients and by servers in
terms of both assurances, detection, and scope of compromise attained.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 12 Apr 2018 21:31:51 +0300

> accept as "from the origin" their content, in an otherwise undetectable

Also, due to the requirement that SC keys are online, even if the key
is protected from dumping, it can still be misused (in realtime) if the
web server is compromised (and such compromise may be difficult to
detect). WP/DC keys do not need to be online.

> provisioning the key themselves.

Getting code signing certificates is much much harder than website
certificates (except EV) anyway. So there the HSM requirement is not
that much of an increase.

Also, here is yet another difference. Required capacity. WP/DC/CS need
fairly little signing capacity, so one could put the keys to a
smartcard or basic USB token (with signing capacity on order of 1-3
signature per second) if one wanted to. However SC needs much more
capacity, so smartcard or basic USB token is not going to cut it.

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 12 Apr 2018 14:41:14 -0400

> capacity, so smartcard or basic USB token is not going to cut it.

If SC was coupled to DC though, doesn't that address some of the concerns?

---

From: Jeffrey Yasskin <[email-masked]>
Date: Fri, 13 Apr 2018 20:35:24 +0000

On Thu, Apr 12, 2018 at 6:37 AM Ryan Sleevi <[email-masked]> wrote:

> The same conversation being had around Secondary Certificates and
> Delegated Credentials is applicable here. In this case, we have an online
> signing entity that fundamentally must be near the edge (to terminate TLS),
> while also granting it the ability to create long-lived signatures (the web
> So no, I don't believe allowing reuse is good. And while some providers
> may do operationally idiotic things (such as reusing the keys between the

Thanks for keeping the audience wide.

I think we already have an incentive for server operators to make the
exchange-signing key accessible from their TLS servers: the TLS server is
in the simplest place to serialize an exchange that matches the content it
would serve to a normal TLS request. That's true even if the TLS server
uses a different signing key for the two purposes. Server operators can
choose to be more careful, but the current specification doesn't really
encourage them to be.

I do agree that we should make a conscious choice between safety and
ease-of-use here, although I hope that choice goes toward ease-of-use.

If we pick safety, even copying Microsoft's code signing practices is
probably not enough: server operators can still plug the HSM into an edge
server, and HSM rate limits wouldn't help since attackers don't need to be
able to sign lots of exchanges. Is there another step that would be more
likely to encourage extra caution?

Jeffrey

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 13 Apr 2018 16:56:38 -0400

On Fri, Apr 13, 2018 at 4:35 PM, Jeffrey Yasskin <[email-masked]>
wrote:

>> I commented on the PR, but in the spirit of bringing things to the list,
>> I think allowing reuse with TLS is a net-negative for security, and we
>> should not do this.
>>
> would serve to a normal TLS request.
>

I'm not sure how this follows, and hope you can explain more why you see
that to be the case. The signing operation for a Signed Exchange does not
require being connected to any serving or hosting infrastructure in order
to create such a package. For bundling of PWAs, for example, one would
presumably create a signed exchange as part of the 'package/deploy' step,
much in the same way one 'compiles' code - as the use cases around PWAs
seem to be of apps aware of how they're being served, in order to make sure
that their bundles are friendly to the use case.

For a case around, say, packaging an article or story, for use in sharing,
where CMS use is heavy, wouldn't it be packaged at the time the story was
'published', on the backend system?

> That's true even if the TLS server uses a different signing key for the
> two purposes. Server operators can choose to be more careful, but the
> current specification doesn't really encourage them to be.
>

Shouldn't they be encouraged to be more careful? :)

The PR demonstrates the biggest argument against allowing - namely, that it
facilitates cross-protocol attacks, and forces reasoning about the
invariants of one protocol when considering the other, as the security of
one will become linked to the invariants of the other. Even if we think
it's safe - such as attempting to mirror the TLS signing format in Signed
Exchanges so that the signatures can be distinguished - the cognitive
overhead alone of trying to reason and model either while evolving both
seems... an undesirable tradeoff for the community and for implementers.

> ease-of-use here, although I hope that choice goes toward ease-of-use.

I'm not sure why this would be desirable. I think, as shown in the
discussions around Secondary Certificates or Delegated Credentials, the
security implications here are a profound rethinking of some of the basic
assumptions that connection-oriented security has made and, for that
matter, the Web Security Model. For that matter, even the H/2 coalescing
has revealed a number of surprising holes and assumptions in the security
and privacy models as deployed by common HTTP servers - for example,
clients that 'block' cookies for a.com finding that their connection is
coalesced to b.com, which sends a cookie, and thus still identifies them
when talking to a.com.

In this regard, doesn't it seem better to err on the extreme side of
safety, and work to incrementally and formally explore opportunities for
ease-of-use, rather than to err for ease-of-use, and find it forever tarred
in hearts and minds through negative security associations?

---

From: Jeffrey Yasskin <[email-masked]>
Date: Fri, 13 Apr 2018 21:34:21 +0000

On Fri, Apr 13, 2018 at 1:56 PM Ryan Sleevi <[email-masked]> wrote:

>>> Just as in the Secondary Certificates discussion, in which key
>>> separation or the enforced-use of Delegated Credentials (which permits, but
>>> does not guarantee, a degree of key separation and protection), I think in
>>> the Web Packaging case, the likely actual deployment of servers, and the
>>> security risks to clients, is a reasonable reason to ensure the
>>> protocol-level separation. Beyond the key protection mechanism, the
>>> differences in signatures here ensures a reduction of risk from
>>> cross-protocol confusion and attacks - something that was previously
>>> intentionally mitigated by enforcing this separation.
>>>

Certainly a publisher *could* sign a bundle or exchange as part of their
compilation process, and that's how I'd want to do it, but especially for
single exchanges, it looks like the implementation will be easier if the
exchange is signed on demand and then memoized.

I believe this is the also the server behavior Ekr was worried about that
caused us to block authentication-related headers (
https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#stateful-headers).
We can tell people not to do it, but if it's easier, a bunch of them will
do it anyway.

That's true even if the TLS server uses a different signing key for the two
>> purposes. Server operators can choose to be more careful, but the current
>> specification doesn't really encourage them to be.
>>
>

But how? Just writing down encouragement or requiring a separate key
doesn't seem sufficient.

> in hearts and minds through negative security associations?

I was totally unclear about which choice I hoped would go toward
ease-of-use. Sorry!

In the choice here of HSMs vs software keys, the cost of safety seems
disproportionately larger than the benefit to me.

The tradeoff between TLS-reusable and not seems much more proportionate, so
I don't have a strong preference. I feel like the incentives are similar,
but the need to consider cross-protocol invariants is an independent
argument for avoiding re-use for now.

Jeffrey

---

From: Yoav Weiss <[email-masked]>
Date: Mon, 16 Apr 2018 23:18:38 +0000

Thanks all for your comments!

Not allowing reuse will result in higher complexity to maintain such certs,
and therefore higher cost to adopt Signed Exchanges (as well as Secondary
Certs, if the same restriction is applied for them).
At the same time, it seems like the risk of use of a compromised cert in a
signed exchange (or a secondary cert) is not negligible.

But, can we come up with a different mitigation technique that may be
easier to deploy?
This is not my field of expertise, so it's fairly possible that I'm Holding
It Wrong™, but what if we allowed certs with the `CanSignHttpExchanges` bit
turned on to serve TLS, but only if their stapled OCSP is fresher than X
(for some value of X)?

IIUC, this will enable us to make sure any cert that is used for both
Signed Exchanges and TLS is not used for more than X after its compromise
is discovered. Assuming that the value of X is small enough, that might be
enough to mitigate the risks for Signed Exchange abuse, while allowing at
least some of the non-abusive use cases.
Origins that would be interested in longer lived Signed Exchanges (e.g. for
the offline-PWA case) can always not use the certs for TLS, and have them
be longer lived (up to 7 days IIRC).

On Fri, Apr 13, 2018 at 2:34 PM Jeffrey Yasskin <[email-masked]>
wrote:

>>>> I commented on the PR, but in the spirit of bringing things to the
>>>> list, I think allowing reuse with TLS is a net-negative for security, and
>>>> we should not do this.
>>>>
>> For a case around, say, packaging an article or story, for use in
>> sharing, where CMS use is heavy, wouldn't it be packaged at the time the
>> story was 'published', on the backend system?
>>
>
> The PR demonstrates the biggest argument against allowing - namely, that
>> it facilitates cross-protocol attacks, and forces reasoning about the
> The tradeoff between TLS-reusable and not seems much more proportionate,
> so I don't have a strong preference. I feel like the incentives are
> similar, but the need to consider cross-protocol invariants is an
> independent argument for avoiding re-use for now.
>
> Jeffrey
>

---

From: Jeffrey Yasskin <[email-masked]>
Date: Mon, 16 Apr 2018 23:29:59 +0000

On Mon, Apr 16, 2018 at 4:18 PM Yoav Weiss <[email-masked]> wrote:

> Not allowing reuse will result in higher complexity to maintain such
> certs, and therefore higher cost to adopt Signed Exchanges (as well as
> Secondary Certs, if the same restriction is applied for them).
> This is not my field of expertise, so it's fairly possible that I'm
> Holding It Wrong™, but what if we allowed certs with the
> `CanSignHttpExchanges` bit turned on to serve TLS, but only if their
> stapled OCSP is fresher than X (for some value of X)?
>
> Origins that would be interested in longer lived Signed Exchanges (e.g.
> for the offline-PWA case) can always not use the certs for TLS, and have
> them be longer lived (up to 7 days IIRC).
>

Note that if a TLS private key is exposed, it's usable in secondary
certificates for the OCSP duration (7 days for now) after it's revoked. If
we require delegated credentials for secondary certificates, they're still
usable for up to 7 days, according to
https://tools.ietf.org/html/draft-ietf-tls-subcerts-00#section-2. That's
the same length of time a leaked private key would useful in signed
exchanges even without the OCSP restriction Yoav's suggesting.

(Yoav's suggestion could be implemented by having two separate extensions:
`CanSignHttpExchanges`, which would be critical and forbid TLS use,
and `CanSignHttpExchangesAndTerminateTLS`,
which would be non-critical, allow TLS use, and shorten the maximum OCSP
life.)

Exploring-the-tradeoffsly yours,
Jeffrey

>>>>> So no, I don't believe allowing reuse is good. And while some
>>>>> providers may do operationally idiotic things (such as reusing the keys
>>>>> between the different certificates), the ecosystem does not incentivize or
>>>>> encourage that.
>>>>>
>>>>
>>> coalesced to b.com, which sends a cookie, and thus still identifies
>>> them when talking to a.com.
>>>

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 17 Apr 2018 14:19:50 -0400

On Mon, Apr 16, 2018 at 7:29 PM, Jeffrey Yasskin <[email-masked]>
wrote:

>> At the same time, it seems like the risk of use of a compromised cert in
>> a signed exchange (or a secondary cert) is not negligible.
>>
> usable for up to 7 days, according to https://tools.ietf.org/
> html/draft-ietf-tls-subcerts-00#section-2. That's the same length of time
> a leaked private key would useful in signed exchanges even without the OCSP
> restriction Yoav's suggesting.
>
> `CanSignHttpExchanges`, which would be critical and forbid TLS use, and `
> CanSignHttpExchangesAndTerminateTLS`, which would be non-critical, allow
> TLS use, and shorten the maximum OCSP life.)
>

I'm not sure that the suggestion really considers the client policy here
(or, perhaps I misunderstood, and it's attempting to explicitly reject it).

If we look at Secondary Certs themselves, a key compromise would be valid
for the lower bound of the lifetime of the certificate or the lifetime of
the last good OCSP response (if the certificate is revoked and the client
enforces an OCSP stapled response). A compromise, however, cannot be
detected by the site operator - thus they cannot get to a position to
request revocation. Further, some CAs pre-date good OCSP responses, for
distributions to CDNs, so we cannot assume that the 'last good' OCSP
response is lower-bounded.

In Subcerts, a key compromise of the delegated credentials, would be for
the validity of that DC key's period. This might be 7 days, might be less,
or might be longer (if the key is reused for multiple DCs) - it's entirely
dependent on the key rotation hygiene. Subcerts talks about DC lifetime,
but I didn't see it equate that with key rotation - which is probably an
oversight in the subcerts spec. However, compromise can nominally be
detected, since it requires an on-path exchange.

In Signed Exchanges, it's the same story as it is for Secondary Certs -
undetectable compromise, for a significantly long lifetime.

I think key reuse between signed exchanges and TLS is fundamentally
enabling cross-protocol attacks and security risks, and don't think the
ease is worth the tradeoff, particularly in that it encourages mixing
offline and online keys, with different threat models and capabilities.
Coupling to OCSP simply tries to couple mitigation, but unfortunately,
mitigation is predicated on detection. Something like signed exchanges, or
subcerts, you fundamentally want to have an offline key that you can
carefully gate access to, and never allow it an online capability.
Encouraging that protocol mixing seems like an unsafe design, even without
a formal analysis.

---

From: Mike Bishop <[email-masked]>
Date: Tue, 17 Apr 2018 18:33:03 +0000

While I share the fuzziness of the crypto realm, this is the sort of direction I’d like to see us consider – whether there’s anything we can do to mitigate key compromises without harming the deployability (as much).  Would it make sense to require a (much?) shorter OCSP lifetime for secondary certificates and signed exchanges?  IIUC, signed exchanges are specifically designed to present the certificate separately from the exchange so that the cert and its properties can be rolled frequently.

Even if clients using a signed exchange need to do an OCSP retrieval in real-time before they can use the exchange they possess locally, that’s likely still faster than re-fetching everything covered by the exchange.  Servers using Secondary Certs can update their stapled OCSP more frequently.

From: Yoav Weiss <[email-masked]>
Sent: Monday, April 16, 2018 4:19 PM
To: Jeffrey Yasskin <[email-masked]>
Cc: [email-masked]; Ilari Liusvaara <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Origin Signed Responses and certificate requirements

Not allowing reuse will result in higher complexity to maintain such certs, and therefore higher cost to adopt Signed Exchanges (as well as Secondary Certs, if the same restriction is applied for them).
At the same time, it seems like the risk of use of a compromised cert in a signed exchange (or a secondary cert) is not negligible.

But, can we come up with a different mitigation technique that may be easier to deploy?
This is not my field of expertise, so it's fairly possible that I'm Holding It Wrong™, but what if we allowed certs with the `CanSignHttpExchanges` bit turned on to serve TLS, but only if their stapled OCSP is fresher than X (for some value of X)?

IIUC, this will enable us to make sure any cert that is used for both Signed Exchanges and TLS is not used for more than X after its compromise is discovered. Assuming that the value of X is small enough, that might be enough to mitigate the risks for Signed Exchange abuse, while allowing at least some of the non-abusive use cases.
Origins that would be interested in longer lived Signed Exchanges (e.g. for the offline-PWA case) can always not use the certs for TLS, and have them be longer lived (up to 7 days IIRC).

On Fri, Apr 13, 2018 at 2:34 PM Jeffrey Yasskin <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Apr 13, 2018 at 1:56 PM Ryan Sleevi <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Apr 13, 2018 at 4:35 PM, Jeffrey Yasskin <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Apr 12, 2018 at 6:37 AM Ryan Sleevi <[email-masked]<mailto:[email-masked]>> wrote:
I commented on the PR, but in the spirit of bringing things to the list, I think allowing reuse with TLS is a net-negative for security, and we should not do this.

The same conversation being had around Secondary Certificates and Delegated Credentials is applicable here. In this case, we have an online signing entity that fundamentally must be near the edge (to terminate TLS), while also granting it the ability to create long-lived signatures (the web package). From an operational standpoint, this incentivizes weak key protection, when the threat model of Web Packaging arguably requires stronger key protection, due to the greater risk being introduced to clients - namely, the ability to deploy misused signatures more widely (from oracles or key compromise).

Just as in the Secondary Certificates discussion, in which key separation or the enforced-use of Delegated Credentials (which permits, but does not guarantee, a degree of key separation and protection), I think in the Web Packaging case, the likely actual deployment of servers, and the security risks to clients, is a reasonable reason to ensure the protocol-level separation. Beyond the key protection mechanism, the differences in signatures here ensures a reduction of risk from cross-protocol confusion and attacks - something that was previously intentionally mitigated by enforcing this separation.

So no, I don't believe allowing reuse is good. And while some providers may do operationally idiotic things (such as reusing the keys between the different certificates), the ecosystem does not incentivize or encourage that.

I think we already have an incentive for server operators to make the exchange-signing key accessible from their TLS servers: the TLS server is in the simplest place to serialize an exchange that matches the content it would serve to a normal TLS request.

I'm not sure how this follows, and hope you can explain more why you see that to be the case. The signing operation for a Signed Exchange does not require being connected to any serving or hosting infrastructure in order to create such a package. For bundling of PWAs, for example, one would presumably create a signed exchange as part of the 'package/deploy' step, much in the same way one 'compiles' code - as the use cases around PWAs seem to be of apps aware of how they're being served, in order to make sure that their bundles are friendly to the use case.

For a case around, say, packaging an article or story, for use in sharing, where CMS use is heavy, wouldn't it be packaged at the time the story was 'published', on the backend system?

Certainly a publisher *could* sign a bundle or exchange as part of their compilation process, and that's how I'd want to do it, but especially for single exchanges, it looks like the implementation will be easier if the exchange is signed on demand and then memoized.

I believe this is the also the server behavior Ekr was worried about that caused us to block authentication-related headers (https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#stateful-headers). We can tell people not to do it, but if it's easier, a bunch of them will do it anyway.

That's true even if the TLS server uses a different signing key for the two purposes. Server operators can choose to be more careful, but the current specification doesn't really encourage them to be.

But how? Just writing down encouragement or requiring a separate key doesn't seem sufficient.

The PR demonstrates the biggest argument against allowing - namely, that it facilitates cross-protocol attacks, and forces reasoning about the invariants of one protocol when considering the other, as the security of one will become linked to the invariants of the other. Even if we think it's safe - such as attempting to mirror the TLS signing format in Signed Exchanges so that the signatures can be distinguished - the cognitive overhead alone of trying to reason and model either while evolving both seems... an undesirable tradeoff for the community and for implementers.

I do agree that we should make a conscious choice between safety and ease-of-use here, although I hope that choice goes toward ease-of-use.

I'm not sure why this would be desirable. I think, as shown in the discussions around Secondary Certificates or Delegated Credentials, the security implications here are a profound rethinking of some of the basic assumptions that connection-oriented security has made and, for that matter, the Web Security Model. For that matter, even the H/2 coalescing has revealed a number of surprising holes and assumptions in the security and privacy models as deployed by common HTTP servers - for example, clients that 'block' cookies for a.com<http://a.com> finding that their connection is coalesced to b.com<http://b.com>, which sends a cookie, and thus still identifies them when talking to a.com<http://a.com>.

In this regard, doesn't it seem better to err on the extreme side of safety, and work to incrementally and formally explore opportunities for ease-of-use, rather than to err for ease-of-use, and find it forever tarred in hearts and minds through negative security associations?

I was totally unclear about which choice I hoped would go toward ease-of-use. Sorry!

In the choice here of HSMs vs software keys, the cost of safety seems disproportionately larger than the benefit to me.

The tradeoff between TLS-reusable and not seems much more proportionate, so I don't have a strong preference. I feel like the incentives are similar, but the need to consider cross-protocol invariants is an independent argument for avoiding re-use for now.

Jeffrey

---

From: Jeffrey Yasskin <[email-masked]>
Date: Tue, 17 Apr 2018 18:44:36 +0000

I'm nervous about shortening OCSP lifetime for signed exchanges because one
of the use cases is for P2P sharing between offline clients. It's true that
the OCSP response is cheap to transfer, but I suspect we can't ask the user
to turn on their mobile data while they're loading the app they got from
their friend, partly because phone OSes aren't designed to just transfer
the one cheap thing when they get online, and partly because the data plan
may be completely used up for the month.

"Just use the non-TLS signing key" bifurcates the set of packages. Even
though many apps will be designed for offline use and so can choose to use
the right kind of certificate, it'd be nice for folks to be able to share
pages served by Akamai too.

Signed exchanges present the certificate separately primarily in order to
share the download between multiple resources using the same certificate.
Other uses are more accidental. :)

I do think we can make it easier to detect stolen keys for signed
exchanges, using an idea similar to
https://lists.w3.org/Archives/Public/ietf-http-wg/2018AprJun/0057.html.

Jeffrey

On Tue, Apr 17, 2018 at 11:33 AM Mike Bishop <[email-masked]> wrote:

> While I share the fuzziness of the crypto realm, this is the sort of
> direction I’d like to see us consider – whether there’s anything we can do
> to mitigate key compromises without harming the deployability (as much).
> Would it make sense to require a (much?) shorter OCSP lifetime for
> secondary certificates and signed exchanges?  IIUC, signed exchanges are
> specifically designed to present the certificate separately from the
> exchange so that the cert and its properties can be rolled frequently.
>
>
>
> Even if clients using a signed exchange need to do an OCSP retrieval in
> real-time before they can use the exchange they possess locally, that’s
> likely still faster than re-fetching everything covered by the exchange.
> Servers using Secondary Certs can update their stapled OCSP more frequently.
>
>
>
> *From:* Yoav Weiss <[email-masked]>
> *Sent:* Monday, April 16, 2018 4:19 PM
> *To:* Jeffrey Yasskin <[email-masked]>
> *Cc:* [email-masked]; Ilari Liusvaara <[email-masked]>;
> HTTP Working Group <[email-masked]>
> *Subject:* Re: Origin Signed Responses and certificate requirements
>
>
>

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 17 Apr 2018 14:51:37 -0400

On Tue, Apr 17, 2018 at 2:44 PM, Jeffrey Yasskin <[email-masked]>
wrote:

> I'm nervous about shortening OCSP lifetime for signed exchanges because
> one of the use cases is for P2P sharing between offline clients. It's true
> that the OCSP response is cheap to transfer, but I suspect we can't ask the
> user to turn on their mobile data while they're loading the app they got
> from their friend, partly because phone OSes aren't designed to just
> transfer the one cheap thing when they get online, and partly because the
> data plan may be completely used up for the month.
>

Note that shortening the OCSP lifetime also requires actions upon CAs, on a
topic that is significantly more complex for them than introducing
additional key usages. If the desire is to make deployability simpler, then
CAs can happily attest that shortening lifetime increases the overall cost
that CAs bear - in terms of bandwidth, but also in terms of computational
overhead if ensuring a proper key splitting. In this regard, splitting the
certificate capabilities improves the deployment scenario, by ensuring that
separate parts of the ecosystem can move at separate paces / adopt separate
policies, without adversely affecting the deployability or agility of other
types.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 17 Apr 2018 22:43:04 +0300

> may be completely used up for the month.

I am also worried if one could get certificates from much shorter OCSP
lifetimes from CAs.

> pages served by Akamai too.

The page itself has some control, so if the page holder can get a
certificate for themselves and the deployment has not been made
unacceptably hard (e.g., any MUST-level key protection requirements),
then the owner should be able to do it themselves, regardless of having
Akamai/Cloudflare or whatever on the front.
 
> https://lists.w3.org/Archives/Public/ietf-http-wg/2018AprJun/0057.html.

One should notice that one of the main uses (at least so "they" claim)
for SC is improved privacy (the other being even more cross-origin CDN
connection reuse). And for the thing to work that way, it has to be
as steathy as possible.

Which makes it pretty hard to contact the origin server in DNS (the
main problem being the IP connection, not so much DNS lookup anymore).

But maybe SE operates differently. However, based on the above, one
can not assume Internet connectivity when using the SE, which would
form another form of constraint.

-Ilari

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 18 Apr 2018 15:12:49 +0000

On Tue, Apr 17, 2018 at 11:19 AM Ryan Sleevi <[email-masked]> wrote:

>> (Yoav's suggestion could be implemented by having two separate
>> extensions: `CanSignHttpExchanges`, which would be critical and forbid TLS
>> use, and `CanSignHttpExchangesAndTerminateTLS`, which would be
>> non-critical, allow TLS use, and shorten the maximum OCSP life.)
>>
>

In case people want to take just the changes removing RSA and the
requirement to support secp384r1, without enabling certificate re-use for
TLS, I've split those out into https://github.com/WICG/webpackage/pull/181.

If folks really want to be able to use RSA keys, please speak up.

Jeffrey