Re: Origin Signed Responses and certificate requirements

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.

On Wed, Apr 11, 2018 at 8:33 PM, Jeffrey Yasskin <jyasskin@chromium.org>
wrote:

> On Mon, Apr 9, 2018 at 11:34 AM Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
>> On Mon, Apr 09, 2018 at 06:25:03PM +0000, Jeffrey Yasskin wrote:
>> > On Mon, Apr 9, 2018 at 10:26 AM Ilari Liusvaara <
>> ilariliusvaara@welho.com>
>> > wrote:
>> >
>> > > On Mon, Apr 09, 2018 at 05:00:28PM +0000, Jeffrey Yasskin wrote:
>> > > > On Mon, Apr 9, 2018 at 5:14 AM Ilari Liusvaara <
>> ilariliusvaara@welho.com
>> > > >
>> > > > wrote:
>> > > >
>> > > > > 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.
>> > > > >
>> > > >
>> > > > Because we've switched to requiring new certificates, I've been
>> toying
>> > > with
>> > > > the idea of being much stricter with the set of allowed certificate
>> > > types.
>> > > > Do y'all think it'd be a good idea to require that everyone using
>> v1 of
>> > > > signed exchanges use exactly one kind of certificate, say secp256r1
>> > > ECDSA?
>> > > > And if we did that, could we allow them to re-use that certificate
>> for
>> > > > their TLS servers?
>> > >
>> > > I do not like that very much...
>> > >
>> >
>> > Thanks. Could you say a little more about why? Which specific other
>> > certificate types do you want to be able to use before we use a v2 to
>> > revise the cryptographic suite? Are you looking for ed25519 support,
>> keys
>> > with a security level higher than 128 bits, the ability to add
>> post-quantum
>> > algorithms, or something else?
>>
>> Pretty much that.
>>
>> > One slightly less bad one would be require certificate that is
>> > > considered ECDSA-type (TLS_ECDHE_ECDSA_WITH_*) in TLS 1.2 (which
>> > > includes EdDSA certificates). Of course, that would be somewhat
>> > > complicated rule.
>> >
>> > Or a certificate usable with "a non-legacy, non-RSA signature algorithm
>> > accepted by TLS 1.3", which today would be ecdsa_secp256r1_sha256,
>> > ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, ed25519, or ed448? Or is
>> > there a TLS 1.2 algorithm you definitely want to use?
>>
>> Well, that is pretty much the same set of certificates as used by
>> TLS_ECDHE_ECDSA_WITH_* in TLS 1.2.
>>
>> > It sounds like you might be fine with using a non-RSA certificate as
>> both a
>> > TLS server certificate and package-signing certificate?
>>
>> Yeah, I consider RSA pretty much legacy.
>>
>
> Thanks. I have a PR implementing this at https://github.com/WICG/
> webpackage/pull/179, which I'd love folks to review.
>
> Jeffrey
>