SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol
draft-dbider-sha2-mac-for-ssh-06

[Ballot comment]
Congratulations! Shortest I-D on the telechat.

I have no objection to the publiscation of this document and just two
small nits.

---

It doesn't really work to use RFC 2119 language in the Abstract.

---

Section 2

  This memo adopts the style and conventions of [RFC4253] in defining
  new data integrity algorithms.

  The following new data integrity algorithms are defined:

I dare say I am overly pedantic, but I don't think the algorithms are
actually defined here, just the identifiers for the algorithms.

[Ballot discuss]
- I'd like to see the -96 bit truncated variants
  disappear as per previous comments. I believe the
  authors are ok with that so this is just so's we all
  remember to do that.

IANA understands that, upon approval of this document, there is a single
IANA Action that must be completed.

In the MAC Algorithm Names subregistry of the Secure Shell (SSH)
Protocol Parameters located at:

http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xml

four new algorithm names will be added to the subregistry as follows:

MAC Algorithm Name Reference Note
---------------------- --------------- -----------
hmac-sha2-256 [ RFC-to-be ] Section 2
hmac-sha2-256-96 [ RFC-to-be ] Section 2
hmac-sha2-512 [ RFC-to-be ] Section 2
hmac-sha2-512-96 [ RFC-to-be ] Section 2

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

Cc: secsh

Reply-To: ietf@ietf.org

Subject: Last Call:  (SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol) to Proposed Standard





The IESG has received a request from an individual submitter to consider

the following document:

- 'SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport

  Layer Protocol'

  as a 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 2012-04-16. 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 memo defines algorithm names and parameters for use of some of

  the SHA-2 family of secure hash algorithms for data integrity

  verification in the Secure Shell (SSH) protocol.  It also updates

  RFC4253 by specifying a new RECOMMENDED data integrity algorithm.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-dbider-sha2-mac-for-ssh/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-dbider-sha2-mac-for-ssh/ballot/





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

This is a request to publish draft-dbider-sha2-mac-for-ssh-03.txt,
"SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport
Layer Protocol", as a Proposed Standard.  This document is an individual
submission to the IETF, and is not the product of any working group.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  The authors and SSH community are requesting publication of this
  document as a Proposed Standard.  This document specifies new
  data integrity algorithms for SSH and updates the SSH specification
  (itself a Proposed Standard) to make the new algorithm RECOMMENDED.
  The document header correctly reflects this.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This memo defines algorithm names and parameters for use of some of
  the SHA-2 family of secure hash algorithms for data integrity
  verification in the Secure Shell (SSH) protocol.  It also updates
  RFC4253 by specifying a new RECOMMENDED data integrity
  algorithm.

Working Group Summary

  This document was discussed on the mailing list of the former
  Secure Shell working group.  While the working group concluded
  in 2006, the mailing list has remained an active forum for SSH
  implementors and the venue of choice for discussion of extensions
  to the SSH protocol.

Document Quality

  The algorithms specified in this document have been successfully
  implemented in multiple SSH implementations.

Personnel

  The Document Shepherd for this document is Jeffrey Hutzelman.
  The responsible Area Director is Sean Turner.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  I have reviewed this document, and any issues raised have been
  resolved to my satisfaction.  I believe the document is now ready
  for IETF-wide review and publication as an RFC.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  This document has undergone review and discussion on the former
  SECSH working group mailing list.  It was reviewed and commented
  upon by several individuals who had been active in the working
  group and remained active on the list, and has been implemented
  multiple times.  I am satisfied that this document has received
  sufficient review.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  I don't believe any particular external review is needed for this
  document.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here.

  I have no particular concerns with this document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  As of this writing, the authors have not yet confirmed that they
  have filed any required disclosures.  In the interest of avoiding
  further delay, I have asked the authors to forward confirmation
  directly to the responsible Area Director.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.

  A search using the tool at https://datatracker.ietf.org/ipr/search/
  did not find any IPR disclosures related to this document.

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

  As noted above, there was extensive discussion of this document
  on the mailing list while it was being written.  The document is
  the direct result of the community's belief that an existing
  non-standardized solution was inadequate to the task.  The resulting
  discussion informed the process of producing this new document,
  and I believe there is solid consensus among the SSH community
  for the result.

  Note that because the SECSH working group is no longer active,
  this document is not the product of an IETF working group and
  there was no explicit WGLC or equivalent.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  There have been no expressions of discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  This document has been run through the idnits tool, and was reviewed
  manually for compliance with requirements not checked by the automatic
  tool.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal review criteria apply to this document.

(13) Have all references within this document been identified as
either normative or informative?

  References have been split appropriately.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  There are no normative references to other documents that are not
  ready for advancement.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  This document contains a normative reference to RFC 2104, an
  informational document which describes the HMAC key hash mechanism.
  This is consistent with current practice within the IETF relating
  to descriptions of cryptographic algorithms.

  This document also contains a normative reference to U.S. Federal
  Information Processing Standard (FIPS) publication 180-3, which
  describes the SHA-2 algorithm family.  While this is not an IETF
  document, as a NIST publication and U.S. federal standard, it is
  suitably stable for use as a normative reference by a protocol
  specification.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.

  This document will update RFC 4253 (the SSH transport protocol) to
  specify a new RECOMMENDED data integrity algorithm.  This is called
  out in the document header and abstract, and is prominent in the
  main body of the document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  This document defines four new SSH data integrity algorithms, which
  are to be registered in the SSH MAC Algorithm Name registry.  This
  is called out in the IANA considerations section, including a list
  of the values to be registered.

  This document creates no new IANA registries.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  This document creates no registries requiring Expert Review.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

  No part of this document is written in a formal language
  requiring such verification.