Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
draft-ietf-ipsecme-esp-ah-reqts-10

[Ballot comment]
I am glad Barry and Adrian have already commented. I roll my eyes, wonder why this document did not reference RFC 6919, and move on with my day.

[Ballot discuss]

Just checking...

Did the WG discuss keeping NULL encryption as a MUST?
If so, that's fine, and I'd appreciate a pointer to the
archive (had a quick look, didn't see it). If not,
wouldn't that discussion be a good idea, given recent
events?  Or, if its so obvious amongst the IPsec
community why NULL encryption is still needed, I will
be in your debt for the education;-)

[Ballot comment]
Barry caught one of my concerns...

I agree that "SHOULD-implement" is open to confusion.

---

Please consider renaming
2.5.  Summary of Changes
to
2.5.  Summary of Changes from RFC 4835

Also please consider adding an introductory line of text in that
section to clarify what it is talking about.

---

It would appear that the editor note in Section 6 is no longer needed.
At least, I removed it and idnits was quite happy.

[Ballot comment]
-- Section 3 --

  Both confidentiality and authentication SHOULD be provided.  If
  confidentiality is not needed, then authentication MAY be provided.
  Confidentiality without authentication is not effective [DP07] and
  SHOULD NOT be used.  We describe each of these cases in more detail
  below.

This says that if you confidentiality is not needed, authentication is *entirely* optional, and there is *no* recommendation being made about the use of authentication alone.  Discussion with Paul indicates that that isn't what's meant, but that (1) the WG wasn't able to agree on better text, and (2) tweaking that sentence isn't going to affect implementations anyway.

I think the failure here is in trying to stuff 2119 language in.  Because the next paragraph goes into more details and uses the 2119 key words (and I think it gets it right), a good option might be to lose the 2119 key words in this short paragraph, and just have this be a lead-in to the next one.  This one explains what you're getting at, and the next one puts in the details with the 2119 language.

Some totally editorial stuff... no response needed either way:

-- Section 4 --
Because you use "SHOULD-", it strikes me that "SHOULD-implement" might be misunderstood to refer only to "SHOULD-" algorithms.  I suggest changing it this way:

OLD
  The algorithms listed as MAY-implement are not meant to be endorsed
  over other non-standard alternatives.  All of the algorithms that
  appeared in [RFC4835] are included in this document, for the sake of
  continuity.  In some cases, these algorithms have moved from being
  SHOULD-implement to MAY-implement algorithms.
NEW
  The algorithms listed as "MAY implement" are not meant to be endorsed
  over other non-standard alternatives.  All of the algorithms that
  appeared in [RFC4835] are included in this document, for the sake of
  continuity.  In some cases, these algorithms have moved from being
  "SHOULD implement" to "MAY implement" algorithms.
END

-- Section 6 --
I wouldn't normally pick on anything in the "Acks" section, but there's this:

  Much of the wording herein was adapted from [RFC4835], the parent
  document of this document.

Actually, only the Security Considerations and one paragraph from the Introduction survive from 4835, and I'd hardly call the rest "adapted".  If you want to leave it as it is, that's fine and this is the last you'll hear from me about it.  But it might make sense to reword that to acknowledge the role of 4835 relative to this document somewhat more accurately.

[Ballot discuss]
-- Section 3 --
This all might be exactly right, but it stands out enough to me that I want to ask the question and have the discussion, in order to make sure.

"Both confidentiality and authentication SHOULD be provided.  If confidentiality is not needed, then authentication MAY be provided."  This says that if you confidentiality is not needed, authentication is *entirely* optional, and there is *no* recommendation being made about the use of authentication alone.  Is that really what you mean?  If I don't need confidentiality, it's perfectly OK for me to skip authentication in all cases, and you don't care?

[Ballot comment]
Some totally editorial stuff... no response needed either way:

-- Section 4 --
Because you use "SHOULD-", it strikes me that "SHOULD-implement" might be misunderstood to refer only to "SHOULD-" algorithms.  I suggest changing it this way:

OLD
  The algorithms listed as MAY-implement are not meant to be endorsed
  over other non-standard alternatives.  All of the algorithms that
  appeared in [RFC4835] are included in this document, for the sake of
  continuity.  In some cases, these algorithms have moved from being
  SHOULD-implement to MAY-implement algorithms.
NEW
  The algorithms listed as "MAY implement" are not meant to be endorsed
  over other non-standard alternatives.  All of the algorithms that
  appeared in [RFC4835] are included in this document, for the sake of
  continuity.  In some cases, these algorithms have moved from being
  "SHOULD implement" to "MAY implement" algorithms.
END

-- Section 6 --
I wouldn't normally pick on anything in the "Acks" section, but there's this:

  Much of the wording herein was adapted from [RFC4835], the parent
  document of this document.

Actually, only the Security Considerations and one paragraph from the Introduction survive from 4835, and I'd hardly call the rest "adapted".  If you want to leave it as it is, that's fine and this is the last you'll hear from me about it.  But it might make sense to reword that to acknowledge the role of 4835 relative to this document somewhat more accurately.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ipsecme-esp-ah-reqts-07, which is currently in Last Call, and has the following comments:

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

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

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

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
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 2014-05-02. 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 Internet Draft is a standards track proposal to update the
  Cryptographic Algorithm Implementation Requirements for ESP and AH;
  it also adds usage guidance to help in the selection of these
  algorithms.

  The Encapsulating Security Payload (ESP) and Authentication Header
  (AH) protocols make use of various cryptographic algorithms to
  provide confidentiality and/or data origin authentication to
  protected data communications in the IP Security (IPsec)
  architecture.  To ensure interoperability between disparate
  implementations, the IPsec standard specifies a set of mandatory-to-
  implement algorithms.  This document specifies the current set of
  mandatory-to-implement algorithms for ESP and AH, specifies
  algorithms that should be implemented because they may be promoted to
  mandatory at some future time, and also recommends against the
  implementation of some obsolete algorithms.  Usage guidance is also
  provided to help the user of ESP and AH best achieve their security
  goals through appropriate choices of cryptographic algorithms.

  This document obsoletes RFC 4835.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/ballot/


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

1. Summary

Yaron Sheffer (IPsecME WG co-chair) is the document shepherd and Kathleen Moriarty is the responsible AD.

This document replaces RFC 4835 in specifying requirement levels for various cryptographic algorithms in the ESP and AH protocols. In the 7 years since that older RFC was published, the security of some algorithms diminished, while other, more secure algorithms were published and widely implemented.

This information is essential for interoperable implementation of the protocols, and so the document is intended to be a Proposed Standard.


2. Review and Consensus

There was lively WG discussion around the specific algorithms and requirement levels, but no major objections. There was wide consensus that the document should be published.

3. Intellectual Property

The authors have stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.


4. Other Points

There are no normative downrefs.

Neither are there any IANA considerations.