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, [EMAIL PROTECTED]
(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 ([EMAIL PROTECTED]) is the PROTO-shephard
Russ Housley ([EMAIL PROTECTED]) is the responsible AD
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
