[IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT)

[Tero Kivinen <[e-mail]>]

Stephen Farrell writes:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-ipsecme-safecurves-05: Yes
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> - Sorry if I'm forgetting how we handle this in IPsec,
> but is an implementation of this RFC expected to support
> both curves? I think it'd be ok to say that 25519 is a
> MUST for folks doing, this but that 448 is optional.  I'm
> also fine if we mean that implementing this means you
> have to support both btw but you don't say (here) that
> that's the case.

In IPsec we do not specify any requirement levels in the actual
algorithm documents. The algorithm documents just allocate the IANA
numbers and specify how they algorithms are used.

Then we have separate documents (new versions soon to be in front of
IESG) specifying the actual mandatory to implement algorithms.

Whether some implementation supports this new RFC is something that
does not have well define answer, as people could say they implement
this RFC if they support one or other, or both curves. Usually people
are just saying they support algorithm RFC if they support one
algorithm from there. I.e., vendors usually say they support RFC2451,
even if they only support 3DES from there, and might not support
CAST-128, RC5, IDEA and Blowfish.

Anyways the mandatory to implement ciphers are specified in the
rfc4307bis [1] and rfc7321bis [2].

These curves are not mentioned there, so they are still going to be
MAY. When we are going to update 4307bis again then we are most likely
going to make them SHOULD+ or even MUST (if there is enough
implementations actually implementing them at that point).

[1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/
[2] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-rfc7321bis/
-- 
[e-mail]