FYI: Document writeup for draft-dbider-sha2-mac-for-ssh-03

[Jeffrey Hutzelman <[e-mail]>]

Below is a copy of my document writeup for the SHA2 document

-- Jeff

(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.