Re: Origin Signed Responses and certificate requirements

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?


> 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? :)

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?