- From: Ilari Liusvaara <ilariliusvaara@welho.com>
- Date: Mon, 9 Apr 2018 21:34:00 +0300
- To: Jeffrey Yasskin <jyasskin@chromium.org>
- Cc: Yoav Weiss <yoav@yoav.ws>, HTTP Working Group <ietf-http-wg@w3.org>
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. -Ilari
Received on Monday, 9 April 2018 18:34:36 UTC