I need to agree with Scott here. In the DNS world, we're slow to adopt new DNSSEC crypto algorithms due to speed of deployment. And DNSSEC has been around so long we have been giving guidance telling people to stop using DSA and MD5.
ed25119 should be more than fine, and others can be added if there needs in the future. tim (not as a chair) On Sat, Mar 11, 2023 at 12:10 AM Scott Kitterman <ietf-d...@kitterman.com> wrote: > 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 > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim >
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
