Re: Origin Signed Responses and certificate requirements

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 <mbishop@evequefou.be> 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 <yoav@yoav.ws>
> *Sent:* Monday, April 16, 2018 4:19 PM
> *To:* Jeffrey Yasskin <jyasskin@chromium.org>
> *Cc:* ryan-ietf@sleevi.com; Ilari Liusvaara <ilariliusvaara@welho.com>;
> HTTP Working Group <ietf-http-wg@w3.org>
> *Subject:* Re: Origin Signed Responses and certificate requirements
>
>
>
> 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 <jyasskin@chromium.org>
> wrote:
>
> On Fri, Apr 13, 2018 at 1:56 PM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
>
>
>
>
>
> On Fri, Apr 13, 2018 at 4:35 PM, Jeffrey Yasskin <jyasskin@chromium.org>
> wrote:
>
> On Thu, Apr 12, 2018 at 6:37 AM Ryan Sleevi <ryan-ietf@sleevi.com> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> Shouldn't they be encouraged to be more careful? :)
>
>
>
> 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 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?
>
>
>
> 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
>
>