Re: Origin Signed Responses and certificate requirements

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