W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: Origin Signed Responses and certificate requirements

From: Jeffrey Yasskin <jyasskin@chromium.org>
Date: Wed, 18 Apr 2018 15:12:49 +0000
Message-ID: <CANh-dXmeLtK_Dc1QAMZr8C0Ni_2Ogn1Kbo3+rzne6PsZORwXXQ@mail.gmail.com>
To: ryan-ietf@sleevi.com
Cc: Jeffrey Yasskin <jyasskin@chromium.org>, Yoav Weiss <yoav@yoav.ws>, Ilari Liusvaara <ilariliusvaara@welho.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Apr 17, 2018 at 11:19 AM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

> On Mon, Apr 16, 2018 at 7:29 PM, Jeffrey Yasskin <jyasskin@chromium.org>
> wrote:
>> On Mon, Apr 16, 2018 at 4:18 PM Yoav Weiss <yoav@yoav.ws> wrote:
>>> 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).
>> 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.)
> 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.

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.

Received on Wednesday, 18 April 2018 15:13:31 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:59 UTC