Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
draft-ietf-ipsecme-rfc7321bis-06
Yes
(Alexey Melnikov)
(Kathleen Moriarty)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Mirja Kühlewind)
(Suresh Krishnan)
Note: This ballot was opened for revision 05 and is now closed.
Alexey Melnikov Former IESG member
Yes
Yes
(for -05)
Unknown
Ben Campbell Former IESG member
Yes
Yes
(2017-03-15 for -05)
Unknown
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 IESG member
Yes
Yes
(for -05)
Unknown
Stephen Farrell Former IESG member
Yes
Yes
(2017-03-14 for -05)
Unknown
- 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 IESG member
No Objection
No Objection
(for -05)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2017-03-15 for -05)
Unknown
"Interoperability with IoT" doesn't parse when I read it -- maybe you mean "for IoT devices to interoperate" or something like that?
Alvaro Retana Former IESG member
No Objection
No Objection
(for -05)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2017-03-16 for -05)
Unknown
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 IESG member
No Objection
No Objection
(for -05)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -05)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -05)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -05)
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -05)
Unknown