On 2021-02-28 at 18:43:19, Werner Koch wrote:
On Sat, 27 Feb 2021 23:53, brian m. carlson said:
I'm interested in seeing if we can require v5 SKESK packets with RSA use
RSA-OAEP with SHA-256 and MGF1-SHA-256 and require that v5 signatures
That would add a lot of additional complexity for no good reason because
RSA will over short or long anyway be replaces by 25519 and 448.
I believe that the current plan was to make RSA must-implement, but
maybe I'm misremembering. If we instead made EdDSA, ECDH, and
Curve25519 must-implement and RSA optional, then this becomes clearly
less important.
If we continue to suggest in any way that people use RSA keys, then we
need to consider this. If we make RSA keys completely optional, then
it's probably fine to just omit this.
I realize this requires implementers to add additional code, but I think
the increase in security is worth it given the number of CVEs we've seen
for padding vulnerabilities. We can tell implementers to avoid this
and replace them with bugs in the way more complext PSS and OAEP.
I'm not sure how these wouldn't be a problem anyway given crypto
libraries already implement them. Presumably such bugs would have
already surfaced in their existing usage and interoperability. For
example, any crypto library used by TLS 1.3 almost certainly implements
RSA-PSS correctly because otherwise it wouldn't interoperate, since all
RSA signatures in CertificateVerify use PSS. S/MIME already supports
RSA-OAEP, so presumably that's already correctly implemented as well.
Are you suggesting that existing implementations have other latent
interoperability bugs that aren't exercised by TLS and S/MIME? Or that
there's something special about OpenPGP that makes it more likely to be
a problem here? Or that implementers are likely to avoid using
well-known existing cryptographic implementations in favor of their own?
I see no reason for it and doubt that this can be viewed as part of the
WG's old and new charter.
The charter specifies this:
- Revision of mandatory-to-implement algorithm selection and deprecation
of weak algorithms
I think it's very clear, based on a history of CVEs, that as practically
implemented, PKCS #1 padding is weak compared to PSS and OAEP. We
should specify padding algorithms that are not weak as part of MUST and
SHOULD algorithms.
--
brian m. carlson (he/him or they/them)
Houston, Texas, US
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp