Re: Origin Signed Responses and certificate requirements

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.

Jeffrey