On Dec 11, 2020, at 13:16, Manfred <[email protected]> wrote: > > Hi Paul, > > Thank you very much for the answer. > About "much better" I see in RFC 7427 that its main purpose is to generalize > the IKEv2 authentication method for ECDSA: > "The current version only includes support for three Elliptic Curve groups, > and there is a fixed hash algorithm tied to each group. This document > generalizes..." > > That is to say that the "old" methods (9, 10, 11) don't seem to be deemed > cryptographically weak or obsolete, do I understand this right?
Correct. It’s main goal is to support new authentication algorithms without requiring an RFC per signature+hash combination. > > The other end I need to connect to is Windows 10 which indeed appears to use > methods 9, 10, and 11 in combination with ECDSA certificates. > More specifically, if e.g. DH ECP384 is set (via > Set-VpnConnectionIPsecConfiguration) then only an ECDSA certificate with the > P-384 curve is allowed (others are rejected with error 13806) That’s unfortunate. We were hoping to avoid having toads support for it. > Reason I mention this is that methods 9, 10 11 could be an interoperability > consideration, that is /iif/ they are cryptographically sound, if not I'd > like to know. > (if EC ciphers can't be used the best it can be done with Windows and > libreswan seems to be MODP2048) I know Windows can do modp8192 and 4096, but the DH groups are a separate issue from the authentication method we were talking about. Libreswan supports the ECP DH groups (and curve25519 / curve448) Paul _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
