Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
draft-ietf-ipsecme-rfc7321bis-06

[Ballot comment]
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

[Ballot comment]
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?

[Ballot comment]

- 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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-ipsecme-rfc7321bis-05.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: draft-ietf-ipsecme-rfc7321bis@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, david.waltermire@nist.gov
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)) to Proposed Standard


The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document:
- 'Cryptographic Algorithm Implementation Requirements and Usage
Guidance
  for Encapsulating Security Payload (ESP) and Authentication Header
  (AH)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-03-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document updates the Cryptographic Algorithm Implementation
  Requirements for ESP and AH.  The goal of these document is to enable
  ESP and AH to benefit from cryptography that is up to date while
  making IPsec interoperable.

  This document obsoletes RFC 7321 on the cryptographic recommendations
  only.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/ballot/


No IPR declarations have been submitted directly on this I-D.

The following is an Essay Style Document Writeup:

1. Summary

The document shepherd is David Waltermire, and responsible area director is Kathleen Moriarty.

This document is intended to obsolete the RFC7321 (Proposed Standard) and define a current mandatory to implement algorithms requirements and usage for IPsec traffic. There is another document draft-ietf-ipsecme-rfc4307bis which does the same changes to the IKEv2, and both of the documents are mostly aligned to be same, except where there are different requirements for algorithms in IKEv2 vs ESP. It is requested that this draft and draft-ietf-ipsecme-rfc4307bis be grouped for completing the publication process.

2. Review and Consensus

The draft had no controversy. The draft has been discussed frequently on the mailing list and a lot of comments have been provided on list by people other than the authors. In addition to mailing list discussions, the draft has been presented and discussed during IETF meetings at Berlin (IETF96) and briefly at Seoul (IETF97). Most of the decisions on the algorithm levels were done already when discussing the companion document rfc4307bis.

3. Intellectual Property

The authors are not aware of any IPRs related to this document or the earlier versions of this document: RFC 7321, RFC 4835, or RFC 4305.

4. Other Points

IDnits complain about the IoT and UNSPECIFIED references, but they are not really references in real sense, but comments marked in []. It also complains that there is an unused reference to RFC4309 which is only referenced in the figure, so id nits fails to see the reference. There are also two references to the obsolete documents RFC2393 and RFC4835. Both of these are intentional. The RFC2393 refers to the LZS compression and this is copy of the text from the IKEv2 IANA registry. The RFC4835 reference is for the previous version of this document and the text refers to the terminology started there.