Re: Origin Signed Responses and certificate requirements

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

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.

If we pick safety, even copying Microsoft's code signing practices is
probably not enough: server operators can still plug the HSM into an edge
server, and HSM rate limits wouldn't help since attackers don't need to be
able to sign lots of exchanges. Is there another step that would be more
likely to encourage extra caution?

Jeffrey

On Wed, Apr 11, 2018 at 8:33 PM, Jeffrey Yasskin <jyasskin@chromium.org>
> wrote:
>>
>> Thanks. I have a PR implementing this at
>> https://github.com/WICG/webpackage/pull/179, which I'd love folks to
>> review.
>>
>