W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: Origin Signed Responses and certificate requirements

From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Mon, 9 Apr 2018 10:47:32 -0400
Message-ID: <CAErg=HHZkEA=f1=LCaEzBxPV1VdvbqGL7mg946sy6a1yVHO-PQ@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: Yoav Weiss <yoav@yoav.ws>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Jeffrey Yasskin <jyasskin@chromium.org>
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.
Received on Monday, 9 April 2018 14:48:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:20 UTC