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/ -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
