Subject: [ietf-dkim] Requesting progression of DKIM threats draft...

From: Stephen Farrell <[email-masked]>
Date: Fri, 05 May 2006 17:02:40 +0100

Hi Russ,

The DKIM WG has completed its work [1] on the threats
draft [2], which is intended to be progressed to become
an informational RFC.

I've attached what I think is required for PROTO
reasons for this draft.

As I'm shepherd, I guess questions/queries/whatever
should be directed to me.

Cheers,
Stephen.

[1] http://mipassoc.org/pipermail/ietf-dkim/2006q1/002947.html
[2] http://www.ietf.org/internet-drafts/draft-ietf-dkim-threats-02.txt

   1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?  Which chair is the WG
        Chair Shepherd for this document?

		Yes. Stephen Farrell <[email-masked]> is shepherd.

   1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?
	
		Yes, the review was fine and we have no concerns other than
		the obvious one that you can never really complete a 
		threat analysis.

		During the WG last call we maintained an issues list, which
		is in the dkim queue on https://rt.psg.com/ All issues were
		closed at the Dallas IETF.

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

		No concerns. 

   1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

		No concerns.

   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?

		Very solid consensus from the WG as a whole, with a very few
		exceptions.

   1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.  (It should be
        separate email because this questionnaire will be entered into
        the tracker).

		No.

   1.g) Have the chairs verified that the document checks out against
        all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
        Boilerplate checks are not enough; this check needs to be
        thorough.

		Yes. 

		The ID nits tool notes the use of the DNS domain 
		anytown.ny.us instead of the more common example.org
		but this is justified since the example needed has to
		have some meaningful hierarchy and this is clearer than
		foo.example.org in this case. 

   1.h) Has the document split its references into normative and
        informative?  Are there normative references to IDs, where the
        IDs are not also ready for advancement or are otherwise in an
        unclear state?  The RFC Editor will not publish an RFC with
        normative references to IDs (will delay the publication until
        all such IDs are also ready for RFC publicatioin).  If the
        normative references are behind, what is the strategy for their
        completion?  On a related matter, are there normative references
        that are downward references, as described in BCP 97, RFC 3967
        RFC 3967 [RFC3967]?  Listing these supports the Area Director in
        the Last Call downref procedure specified in RFC 3967.

		This is fine since there are only informative references. There 
		are references to other WG documents that are not yet complete 
		so this document will stay in the rfc editor's queue or else
		can have be progressed referencing these I-Ds.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 05 May 2006 21:40:36 +0100

Of course I forgot some bits. These are they:

Russ Housley wrote:
> The write-up also needs to include these three sections ....
> 
> Technical Summary

    This document provides an analysis of some threats against Internet
    mail that are intended to be addressed by signature-based mail
    authentication, in particular DomainKeys Identified Mail.  It
    discusses the nature and location of the bad actors, what their
    capabilities are, and what they intend to accomplish via their
    attacks.

> Working Group Summary

    The working group fairly easily reached consensus on the specific
    threats and on how to document them. A couple of participants had
    concerns that the threats draft contained insufficient detail or
    was closing off design options for later, but these participants
    seem also to accept that the WG should move on to protocol design.

> Protocol Quality

    As this is a threat analysis there is no issue of implementation.
    The WG chairs solicited review from some current and former IAB
    members and did get some review from one, who while perhaps not
    entirely pleased with DKIM, nonetheless helped improve the
    document. The main issue with such an analysis is that you can
    never know you've completed the work, so additional review and
    insight will be welcomed whenever it turns up. Having said that
    the WG did expend significant effort on this document both in
    creating text and review.

Stephen.