Re: Origin Signed Responses and certificate requirements

On Mon, Apr 9, 2018 at 8:14 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Mon, Apr 09, 2018 at 11:54:26AM +0000, Yoav Weiss wrote:
> > Hey all,
> >
> > While reviewing the Origin Signed Responses draft, I noticed that the
> > certificate
> > requirements
> > <https://wicg.github.io/webpackage/draft-yasskin-http-
> origin-signed-responses.html#cross-origin-cert-req>
> > section
> > requires the signing certificate to have a specific opt-in to response
> > signing while also prohibiting such certs from serving TLS connections.
> >
> > >From a deployment perspective, the second requirement means that an
> entity
> > which wants to sign packages as well as terminate TLS connections would
> > have to maintain multiple certs for each domain, which will significantly
> > increase complexity.
> >
> > I'm wondering regarding the reasoning behind that second requirement. Why
> > can't certs which opt-in to signing packages also be able to serve TLS?
> > What are the risks involved?
>
> Specifically, this is because RsaEncryption keys can be used with
> insecure static RSA key exchange that will yield a signing oracle
> if one gets it even slightly wrong. And such oracles would be very
> bad thing in context like this.
>
> In theory, this would not be needed for RSA-PSS, ECC or EdDSA
> keys. But this requirement appiles even to them in name of
> consistency.
>

Ilari is spot-on.

One further note to add: This is also about the difference between the
server's expected/desired security properties and the client's
expected/desired security properties. That is, a server may be fully
cognizant of the risk that a signing oracle poses and take steps to
mitigate, and thus may argue that they should be able to use a single
certificate for both cases. And while they may do so successfully, the
client has no way of distinguishing between a server that is cognizant -
and has taken steps to mitigate - and a server that is not cognizant, and
thus risky. Thus the proposed protocol-level separation of these concerns.

To some extent, these concerns are also relevant to the CERTIFICATE frame -
whether or not the tradeoff in security property necessitates some form of
opt-in by the server (to indicate awareness of the issues - such as key
compromise), and whether there needs to be a protocol layer separation for
clients to ensure that. Of course, alternative solutions may and likely do
exist for the CERTIFICATE frame, given the online nature of the exchange.