[ietf-dkim] Re: DKIM BOF -- draft charter and agenda

[Barry Leiba]

Time for the next pass, after input from several of you, on and off the
list, and input from Russ as well.  The attached version covers pretty
much everything, and I think we might be done with the charter now.
Can we close on this, and work up an agenda for the BOF?

The only significant comment that I think I haven't done anything about
is from Ned: you suggested including words about canonicalization and
hashing, along with those about public-key crypto.  I decided that the
reference to p-k crypto is sufficient to specify the mechanism in the
charter (distinguishing it, for instance, from looking at IP addresses,
or the Farmer's Almanac), and that getting into "we canonicalize the
message, take a hash of that, digitally sign that, put the result into
the header..." is really what the spec is for.  So I left that as it
was.  If you *really* think mentioning c<237>n and hashing is very
important for the charter, please bring it up again.

Barry

--
Barry Leiba, Pervasive Computing Technology  (leiba at watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
-------------- next part --------------
DRAFT IETF WORKING GROUP CHARTER  
14 Oct 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 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 allow receiving domains to detect (or rule out) spoofing in many 
circumstances.

The DKIM working group will produce summaries 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.  

While the techniques specified by the DKIM working group will not prevent 
fraud or spam, they will provide a valuable tool for defense against them by 
allowing receiving domains to detect spoofing of known domains.  The 
standards-track specifications will not mandate any particular action by the 
receiving domain when spoofing is detected.  The DKIM working group will not 
attempt to define such actions, to establish requirements for trust 
relationships between domains, or to specify reputation or accreditation 
systems.  

The signatures will use public-key cryptography and will be based on domain 
name identifiers.  Public keys needed to validate the signatures will be 
stored in the responsible identity's DNS hierarchy.  The specifications will 
be based on the following Internet Drafts: 

* draft-fenton-dkim-threats
* draft-allman-dkim-base
* draft-allman-dkim-ssp

which represent experimentation and consensus from a number of designers and 
early implementors.  
 
Since experimentation resulted in significant Internet deployment of these 
specifications, the DKIM working group will make every reasonable attempt to 
keep changes compatible with what is deployed, making incompatible changes 
only when they are necessary for the success of the specifications.  

The resulting protocols must meet typical criteria for success.  In addition 
to security, these include usability, scalability, ease of deployment, and 
cryptographic algorithm independence.  

To prevent this task from becoming unwieldy, several related topics are
considered out of scope for the DKIM working group.  These topics include:

* Reputation and accreditation systems.  While we expect these to add value 
  to what is defined by the DKIM working group, their development will be 
  separate, and is out of scope for the DKIM working group.  

* Message content encryption.  

* Additional key management protocols or infrastructure.  

* Signatures that are intended to make long-term assertions beyond the 
  expected transit time of a message from originator to recipient, which is 
  normally only a matter of a few days at most.  

* Signatures that attempt to make strong assertions the identity of the 
  message author, and details of user-level signing of messages (as 
  distinguished from domain-level keys that are restricted to specific 
  users).

* Duplication of prior work in signed email, incuding S/MIME and OpenPGP.  

Once the primary goals are met, the DKIM working group may also study 
whether to adopt a work item for specifying a common mechanism to 
communicate the results of message verification to the message recipient.  
The generation of a standards-track specification will require an update to 
the DKIM working group charter.  

The deliverables for the DKIM working group are: 

* an informational RFC providing an overview of DKIM, how it can fit
  into overall messaging systems and outlining potential DKIM applictions
  and future extensions
* an informational RFC presenting a detailed threat analysis of, and 
  security requirements for, DKIM
* 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


GOALS AND MILESTONES:

02/06     WG last call on DKIM threats and security requirements
05/06     WG last call on DKIM signature specification
09/06     WG last call on DKIM policy specification
12/06     WG last call on DKIM DNS Resource Record
12/06     WG last call on overview document