Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC 8221

Note: This ballot was opened for revision 05 and is now closed.

(Ben Campbell) Yes

Comment (2017-03-15 for -05)
No email
send info
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?

(Stephen Farrell) Yes

Comment (2017-03-14 for -05)
No email
send info
- 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

Alexey Melnikov Yes

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Comment (2017-03-16 for -05)
No email
send info
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

Alissa Cooper No Objection

Comment (2017-03-15 for -05)
No email
send info
"Interoperability with IoT" doesn't parse when I read it -- maybe you mean "for IoT devices to interoperate" or something like that?

(Joel Jaeggli) No Objection

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

Alvaro Retana No Objection