On Friday, March 10, 2023 2:32:36 PM EST Jan Dušátko wrote: > Dear, > I would like to recommend change/extend support of algorithms for DKIM > signage. Last update of algorithms are in RFC 8463, still not widely > supported. Right now we facing issues with the long DKIM key > distribution and lack of support, allowing the ECC signature can solve > problem with key size. > > Elliptic curve signatures: > I would like to recommend not only Ed25519, but also Ed448. Thanks to > clever design, signatures based on on that algorithms can avoid of nonce > collisions. But this could be real risk for the DSS standard curve > implementation. > > | Key size | Curve | Nonce | Security Equivalent > > | Hash | > > ----------+----------+-----------------+----------+---------------------+--- > -------+ Ed25519 | 255b | Twisted Edwards | Text+Key | 125b | SHA256 > | Ed448 | 448b | Twisted Edwards | Text+Key | 224b | SHAKE256 | > NIST P256 | 256b | Weierstrass | Random | 128b | SHA256 | NIST > P384 | 384b | Weierstrass | Random | 192b | SHA384 | NIST P521 > | 521b | Weierstrass | Random | 230b | SHA512 | > > RSA signatures: > But the RSA signature, require extremely long private keys. To assure > similar security equivalent, need to be at the least 12 times longer. > But RSA have sub-exponential complexity. > > Key size | Security Equivalent | > ---------+---------------------+ > 1024b | 96b | > 2048b | 112b | > 3072b | 128b | > 4096b | 160b | > > The signature based on RSA has some issues, but based on key properties > nobody will be able to decide between them. In case of change required, > need to be mentioned i DKIM key. Use of k=rsa for PKCS#1 v 1.5 as > default value or k=rsa-pss for PKCS#1 v 2.2 RSA-PSS are probably the > only solution. > PKCS#1 v 1.0, obsolete, has not been supported > PKCS#1 v 1.5, obsolete, vulnerable by Bleichenbacher family of attacks > PKCS#1 v 2.2 RSA-PSS (DSS standard), described in NIST FIPS 186-5 > > Support: > EU directive eIDAS and ETSI standard ETSI TS 119312 support signatures > based on RSA PKCS#1 v 1.5, RSA-PSS, ED25519, ED448, NIST P-256, NIST > P-384, NIST P-521 > NIST FIPS 186-5 support signatures based on RSA PKCS#1 v 1.5, RSA-PSS, > ED25519, ED448, NIST P-256, NIST P-384, NIST P-521 > RFC 8446 TLS 1.3 support signatures based on RSA PKCS#1 v 1.5, RSA-PSS, > ED25519, ED448, NIST P-256, NIST P-384, NIST P-521
Specifying more algorithms than we need is a hindrance to interoperability. We added ed25519 so that we would have a specified alternative if RSA suddenly became unusable. In order to be interoperable, the signer and receiver both need to support the same algorithms. Today that common algorithm is RSA. I've dual signed email with both RSA and ed25119 since even before the DCRUP working group published RFC 8463, but I don't recall having ever noticed receiving an ed25119 based DKIM signature. As you note, it's deployment has been sparse. The solution to the lack of sufficient deployment for interoperability of an alternative to RSA is to push for ed25119 deployment, not to add more choices. Scott K _______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
