Re: Origin Signed Responses and certificate requirements

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.