Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 8247
Yes
(Kathleen Moriarty)
(Stephen Farrell)
No Objection
Alvaro Retana
(Alexey Melnikov)
(Alia Atlas)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
Note: This ballot was opened for revision 15 and is now closed.
Alvaro Retana
No Objection
Ben Campbell Former IESG member
(was No Objection)
Yes
Yes
(2017-03-15 for -17)
(oops, meant to ballot "yes". Fixed now.) Section 2.1, 2nd to last paragraph says that ENCR_3DES has been downgraded to SHOULD NOT. But both the table in this section, and the change table later in the draft say MAY.
Kathleen Moriarty Former IESG member
Yes
Yes
(for -15)
Stephen Farrell Former IESG member
Yes
Yes
(for -17)
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -15)
Alia Atlas Former IESG member
No Objection
No Objection
(for -17)
Benoît Claise Former IESG member
No Objection
No Objection
(2017-02-10 for -15)
Here is Sue Hares' OPS DIR feedback: Status: Read for publication with editorial nits (see below) General Comment: Thank you for this interesting, informative, and well-written draft. My editorial nits are just places you might improve the clarity of the draft. Sue Hares ======================= Editorial Nits: #1 – Section 1.3, p 4, paragraph 1 Old/The recommendations of this document mostly target IKEv2 implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. / New: /The recommendations of this document mostly target IKEv2 implementation as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. / Note: Either implementation as implementations Or implementers as implementers need to create implementations #2 – section 1.3, p. 4,paragraph 2 3) Old/ This document does not give any recommendations for the use of algorithms, it only gives implementation recommendations for implementations./ New / This document does not give any recommendations for the use of algorithms, it only gives implementation recommendations regarding implementations./ #3 section 3.1, p. 6 , paragraph 2, starting with “ENCR_CHACHA20_POLY1305” Please expand the abbreviation CRFG. I believe this this is the first use of the abbreviation. #4 section 3.4, p 9-10, several paragraphs in here did not provide the final status 4.a p9, last paragraph on page old/ Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 as a replacement for 1024-bit MODP Group. / new/ Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 to MUST as a replacement for 1024-bit MODP Group. / 4.b p. 9, first paragraph on page, line 1 Old/ Group 19 or 256-bit random ECP group was not specified in RFC4307, as this group were not defined at that time. Group 19 is widely implemented and considered secure./ New / Group 19 or 256-bit random ECP group was not specified in RFC4307, as this group were not defined at that time. Group 19 is widely implemented and considered secure so Group 19’s status is SHOULD. 4.c p.9, paragraph 4, line Old/ Group 1 or 768-bit MODP Group was not mentioned in RFC4307 and so its status was MAY. It can be broken within hours using cheap of-the- shelves hardware. It provides no security whatsoever./ New/ Group 1 or 768-bit MODP Group was not mentioned in RFC4307 and so its status was MAY. It can be broken within hours using cheap of-the- shelves hardware. It provides no security whatsoever. Therefore, its current stsatus is MUST not. #5 section 4.1, p 12, paragraph 2-4: Final status not indicatd 5.a: paragraph 2 Old/ Shared Key Message Integrity Code is widely deployed and mandatory to implement in the IKEv2 in the RFC7296./ New:/ Shared Key Message Integrity Code is widely deployed and mandatory to implement in the IKEv2 in the RFC7296. The status is MUST. / 5.b paragraph 3 Old/ ECDSA based Authentication Methods are also expected to be downgraded as it does not provide hash function agility. Instead, ECDSA (like RSA) is expected to be performed using the generic Digital Signature method. / New/ ECDSA based Authentication Methods are also expected to be downgraded as it does not provide hash function agility. Instead, ECDSA (like RSA) is expected to be performed using the generic Digital Signature method. ECADSA-based Authentication Methods status is “SHOULD”. / 5.c. paragraph 4 Old:/ DSS Digital Signature is bound to SHA-1 and has the same level of security as 1024-bit RSA. It is expected to be downgraded to MUST NOT in the future./ New/ DSS Digital Signature is bound to SHA-1 and has the same level of security as 1024-bit RSA. It is currently at SHOULD NOT, but it is expected to be downgraded to MUST NOT in the future./ 5.d paragraph 5 Old/ Digital Signature [RFC7427] is expected to be promoted as it provides hash function, signature format and algorithm agility./ New/ Digital Signature [RFC7427] is expected to be promoted as it provides hash function, signature format and algorithm agility. Its current status is SHOULD.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -15)
Jari Arkko Former IESG member
No Objection
No Objection
(for -17)
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -17)
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -17)
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -17)
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -17)