Re: Origin Signed Responses and certificate requirements

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.)

Exploring-the-tradeoffsly yours,
Jeffrey

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
>>
>