Subject: [IPsec] draft-ietf-ipsecme-safecurves-00 and IKEv2 in OpenBSD

From: Reyk Floeter <[email-masked]>
Date: Fri, 9 Oct 2015 19:22:28 +0200

Hi,

OpenBSD includes IKEv2 support since the 4.8 release in 2010. The
software aka. OpenIKED is an independent, ISC-licensed, and open
source implementation that focusses on simplicity and proactive
security.  I'm the main author but it has turned into a group effort
with a number of contributors. See http://www.openbsd.org/ and and
http://www.openiked.org/ for more details.

While keeping the code base lean, we do support a number of IKEv2
extensions and crypto algorithms.  We're especially interested in two
recent activities of the working group:

1. RFC 7634 "ChaCha20, Poly1305, and Their Use in the Internet Key
Exchange Protocol (IKE) and IPsec":

I appreciate the addition of chacha20-poly1305 and it will be added to
iked soon (first for IKESAs before CHILDSAs).  We support the proposed
addition to RFC 4307.

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.

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.

Reyk

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 12 Oct 2015 23:27:27 +0200

> future update of RFC 4307.

Thanks for feedback!

> 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