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 : Thursday, 2 February 2023 18:43:59 UTC