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

Re: Origin Signed Responses and certificate requirements

From: Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Mon, 9 Apr 2018 18:07:42 +0300
To: Ryan Sleevi <ryan-ietf@sleevi.com>
Cc: Yoav Weiss <yoav@yoav.ws>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Jeffrey Yasskin <jyasskin@chromium.org>
Message-ID: <20180409150742.GA31746@LK-Perkele-VII>
On Mon, Apr 09, 2018 at 10:47:32AM -0400, Ryan Sleevi wrote:
> 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.
> 
> 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.

The CERTIFICATE frame does have secure nonce, but due to much longer
attack window than with exchange signatures, perhaps oracle attacks
could be practical.

Another place that has some real concenrs with oracles is sub-
certificates proposal (which is a WG document).


-Ilari
Received on Monday, 9 April 2018 15:08:21 UTC

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