[ietf-dkim] DKIM charter

[Jim Fenton]

Barry,

This is very good, and entirely acceptable IMO.  I have a few 
suggestions for what they're worth; take them or leave them as you please.

Barry Leiba wrote:

> ---------------------------------------------------------------------
> DRAFT IETF WORKING GROUP CHARTER
> 8 Nov 2005
>
>
> Domain Keys Identified Message (DKIM)
>
>
> CHAIRS:
>      TBD
> AREA DIRECTORS:
>      Russell Housley, Sam Hartman
> AREA ADVISOR:
>      Russell Housley <housley at vigilsec.com>
> MAILING LISTS:
>     General Discussion: ietf-dkim at mipassoc.org
>     To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim
>     Archive: http://mipassoc.org/pipermail/ietf-dkim/
>
> DESCRIPTION OF WORKING GROUP:
>
> The Internet mail protocols and infrastructure allow mail sent from one
> domain to purport to be from another.  While there are sometimes 
> legitimate
> reasons for doing this, it has become a source of general confusion, 
> as well
> as a mechanism for fraud and for distribution of spam (when done
> illegitimately, it's called "spoofing").  The DKIM working group will

The parenthetical seems to be a bit misplaced, and might fit better to 
the use of the word "legitimate".  This might read more easily if broken 
into two sentences.

> produce standards-track specifications that allow a domain to take
> responsibility, using digital signatures, for having taken part in the
> transmission of an email message and to publish "policy" information 
> about
> how it applies those signatures.  Taken together, these will
> assist receiving domains in detecting (or ruling out) certain forms of
> spoofing as it pertains to the signing domain.

Detection of spoofing is indirect at best; I'd prefer that we emphasize 
the ability of DKIM to rule out spoofing.

I really like your suggestion in 
http://mipassoc.org/pipermail/ietf-dkim/2005q4/001359.html that we move 
away from the word "policy" and use "declaration".  Should we do that 
here as well?  I have one concern about this:  we still need to discuss 
what the SSP/SSD/SSx says, and whether it would include something to the 
effect, "Please deal harshly with messages that don't conform with this 
declaration" or "Please don't take this declaration very seriously".  
This is similar to what the testing flag in the current SSP draft says.  
These statements aren't really declarative; they're a request, and I'd 
rather that the choice of words not preempt this discussion.

>
> The DKIM working group will produce a summary of the threats that are
> addressed by the standards-track specifications, while acknowledging 
> their
> limitations and scope.  The DKIM working group will also produce security
> requirements to guide their efforts, and will analyze the impact on 
> senders
> and receivers who are not using DKIM, particularly any cases in which
> mail may be inappropriately labeled as suspicious or spoofed.

I got a little confused by the use of "standards-track specifications" 
here, because the threat analysis is done before any standards-track 
specifications exist.  Should it say "DKIM specifications" instead?

>
> While the techniques specified by the DKIM working group will not prevent
> fraud or spam, they will provide a tool for defense against them by
> assisting receiving domains in detecting some spoofing of known domains.
> The standards-track specifications will not mandate any particular 
> action by
> the receiving domain when a signature fails to validate.  That said,
> with the understanding that guidance is necessary for implementers, 
> the DKIM
> documents should discuss a reasonable set of possible actions and 
> strategies,
> and analyze their likely effects on attacks and on normal email delivery.
> The DKIM working group will not attempt to establish requirements for 
> trust
> relationships between domains or to specify reputation or accreditation
> systems.

Last sentence: "or" -> "nor"

>
> The DKIM working group will consider mailing-list behaviour that is
> currently deemed acceptable, will make every effort to allow such
> mailing lists to continue to operate in a DKIM environment, and will
> provide a plan for smooth transition of mailing lists that fail to
> operate.  The specs will also advise mailing lists on how to take
> advantage of DKIM if they should choose to do so.

"specs" (which should probably be spelled out) is plural.  Is that to 
say that all of the documents will say something about mailing lists?  I 
tend to think that this is somewhat of a higher-level issue than the 
-base document addresses.

[snip]

> The deliverables for the DKIM working group are these:
>
> * An informational RFC providing an overview of DKIM and how it can fit
>   into overall messaging systems, implementation and migration
>   considerations, and outlining potential DKIM applications and future
>   extensions.
> * An informational RFC presenting a detailed threat analysis of, and
>   security requirements for, DKIM.  IESG approval of this document is a
>   prerequisite for the submission of the standards-track specifications.

Is this typical for threat/security requirements documents?  How long is 
it likely to take (and is it likely to interfere with the schedule for 
the signature schedule specification Last Call)?

> * A standards-track specification for DKIM signature and verification.
> * A standards-track specification for DKIM policy handling.
> * A standards-track specification for a DKIM DNS Resource Record.

The current drafts have two DKIM RRs, one for keys and another for 
"policy".  So that should be Resource Records.  Hopefully we can still 
fit them into a single specification.

-Jim