[Int-area] Progressing draft-bagnulo-multiple-hash-cga

["James Kempf" <[e-mail]>]

I've volunteered to be the draft shepherd for 
draft-bagnulo-multiple-hash-cga, which is an extension to RFC 3972 to allow 
CGAs to utilize multiple hash algorithms. This is in response to the a 
potential future attack that may evolve out of the recent cryptanalysis 
results on SHA-1. The latest version of the draft is here:

http://www.geocities.com/kempf42/draft-bagnulo-multiple-hash-cga-02.txt

This draft is not a product of a WG, but I thought I'd use the INT area list 
for any comment, since it is an INT area item. The draft was presented at 
the Monteral meeting, and comment was favorable.

Below is the proto-shepherd writeup for the draft. I would like to submit it 
and the draft to Russ Housley, who'll be taking it through the IESG, next 
Wednesday. So if you have any comments, please send them to the list by 
then. If it turns out that there's lots of comment and discussion, I can 
postpone the submission date, but I'm going on vacation for a while on Feb. 
3 and I'd like to get the draft in before that. If we need to postpone, I'll 
review the list traffic and make some recommendations when I get back after 
March 3.

            jak

---------------------------------------------------------
   (1.a)
    (1.a.i) Who is the Document Shepherd for this document?

          James Kempf, [e-mail]

    (1.a.ii) Has the Document Shepherd personally reviewed this version of 
the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

   Yes.

   (1.b)
    (1.b.i) Has the document had adequate review both from key WG members
            and from key non-WG members?

          This document is not a product of a WG. It has been reviewed by
         Christian Vogt, Pekka Nikander, and Henrik Levkowetz.

    (1.b.ii) Does the Document Shepherd have any concerns about the depth
             or breadth of the reviews that
             have been performed?

          No.

   (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

          No.

   (1.d)  Does the Document Shepherd have any specific concerns or
          issues 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 WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.

          No.

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

          This document is not a product of a WG.

   (1.f)  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
          entered into the ID Tracker.)

          No.

   (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

          Yes. Idnits shows no issues.

    (1.h)
     (1.h.i) Has the document split its references into normative and
             informative?

             Yes.

     (1.h.ii) 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
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

   No.

   (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggested a
          reasonable name for the new registry?  See
          [I-D.narten-iana-considerations-rfc2434bis].  If the document
          describes an Expert Review process has Shepherd conferred with
          the Responsible Area Director so that the IESG can appoint the
          needed Expert during the IESG Evaluation?

          There is an IANA Considerations section, it does request a
          new registry, and the proposal seems consistent with RFC2424bis.

   (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

          There are none.

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

          Here is the document summary:

          Technical Summary
              This document analyzes the implications of recent attacks on
              commonly used hash functions on Cryptographically Generated
              Addresses (CGAs) and updates RFC 3972 to support
              multiple hash algorithms. An IANA registry is established
              to register hash functions for CGAs.


          Working Group Summary
              This document is not a product of a Working Group.

          Document Quality
        Since the protocol described in the document is designed
               to "future-proof" CGAs against attacks that have not
               yet occured, it has not yet been deployed. It depends on
               a new IANA registry being established and will require
        simple modifications to the SEND protocol.

          Personnel
       James Kempf (kempf@docomolabs-usa) is the PROTO-shephard
       Russ Housley ([e-mail]) is the responsible AD



_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area