Reyk Floeter <[email protected]> writes: > 2. draft-ietf-ipsecme-safecurves-00 "Curve25519 and Curve448 for IKEv2 > Key Agreement": > > iked supports Curve25519 since August 2014. I compared the draft with > our implementation and it matches the described application. We're > currently using an xform type 4 id from the private space, but we hope > to switch to an official id once it is assigned by IANA. > > Curve25519: We hope that the addition of Curve25519 will be finalized > in an RFC. We also hope that it will be added as SHOULD or MUST in a > future update of RFC 4307.
Thanks for feedback! > Curve448: We discussed Curve448 internally and we are not going to add > the curve at this point. Compared to Curve25519 it had much less > cryptographer review, provides a less proven and more complex > reference implementation, and is basically "too new". We also think > that Curve25519 provides sufficient security at present. Afaik, there > are no plans to add Curve448 in OpenSSH or LibreSSL either. The draft > should clarify Curve448 as an optional extension for potentially > higher security levels or omit it completely. > > We're not fully convinced of the meaningfulness of the security levels > in this regard. After all, Curve25519 is a solid choice. I can understand these concerns for an implementer. I think there is little harm in the draft specifying how to use Curve448 for potential future use though. I agree normative language or mandatory-to-implement recommendations for Curve448 may be premature, at least until other implementers speak up in favor of implementing it. /Simon
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
