Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC 8221
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
Alvaro Retana No Objection
(Alexey Melnikov; former steering group member) Yes
(Ben Campbell; former steering group member) Yes
I'm balloting "Yes", but I have a few minor comments/questions: - Abtstract: "This document obsoletes RFC 7321 on the cryptographic recommendations only." I'm not sure what that means. Does the reader of this still need to read 7321? If so, is "obsoletes" the correct relation? -3: I wonder why "... is not to be used..." is not "... MUST NOT be used...". But the section goes on to say if you do it anyway, you MUST NOT use certain cryptosuites. So, does "... is not to be used..." mean "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL" sort of requirements? - Table in section 6: I'm boggled by the first entry being labeled "MUST/MUST NOT". I don't see anything in the text to explain the "MUST" part--did I miss something?
(Kathleen Moriarty; former steering group member) Yes
(Stephen Farrell; former steering group member) Yes
- I agree with Christian's secdir review [1] that this doesn't seem justified (at least on it's face): " If manual keying is used anyway, ENCR_AES_CBC MUST be used, and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be used as these algorithms require IKE. " Can you explain the reasoning that lead the WG to say that? - ENCR_NULL IMO ought be MUST NOT - did the WG discuss that explicitly? If so, can you provide a pointer to the archive? If not, does it still have to be a MUST? I do wonder who wants to use AH via NAT but cannot, which seems to be the justification. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg07262.html
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
"Interoperability with IoT" doesn't parse when I read it -- maybe you mean "for IoT devices to interoperate" or something like that?
(Benoît Claise; former steering group member) No Objection
As discussed based on the OPS DIR review: Hi Paul, To avoid any future questions, are your 3 justifications below mentioned in the draft? Regards, Benoit > On 03/13/2017 07:17 AM, Sheng Jiang wrote: > > Hello Sheng, > > thanks for your review! > >> Comparing with RFC 7321, this document uses different names for algorithms. Although it looks consistent, it may reduce readability a little. The below items, I would like to double check for consistent. >> >> >> >> 3DES ?= TripleDES-CBC (old) >> >> DES ?= DES-CBC (old) >> >> AES_XCBC_96 ?= AES-XCBC-MAC-96 (old) > e actually changed all names to match the actual IANA IKEv2 entries at http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml > >> There are a few new algorithms mentioned, without any description or analysis. Additional explanation should be needed. >> >> >> DES_IV64 >> >> DES_IV32 >> >> 3IDEA > Those are old reserved entries that have no implementation and therefor actually have no RFC we can point to. Which is also why we made > it very clear these are MUST NOT. > >> I actually have more concerns regarding to the below algorithm that is mentioned in RFC7321, but not in this document. Does it create a new hole? >> >> >> AES-CTR [RFC3686] > It was mentioned in 7321 because it went from SHOULD to MAY. > > It is not mentioned in 7321bis because it is still at MAY, and we do not list any algorithms in MAY. > > I hope this clarifies your questions, > > Paul
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection