[Top] [All Lists]

Re: DKIM BOF -- draft charter and agenda

2005-10-13 07:45:21
OK, I've let this simmer for a couple of days, and I think it's time
to come back with my take on it, as the other BOF chair, and as someone
who's worked on the specs as they currently are.  I'm including Russ
as a CC on this message, asking him (Hi Russ!) explicitly to comment.

As I said in my previous note, I had a couple of issues with the
draft charter as it was, and I agreed with some of Stephen's comments.
I also agree with what Dave, Jim, Mike, and some others have said about
questioning the value of a too-extensive rewrite of the charter (though
that might be what I'm posting here anyway, since I tend to rewrite,
when I get my hands on stuff).  I think I've got a good compromise,
which I'm attaching here.

It keeps the general flavour of the original charter, and expands
the text a bit in the areas where some have said it's lacking.  I've
rearranged and reworded some things, without, I hope, completely
changing it.  And I've revised the milestones to be what I think are
feasible, and still aggressive.

I left out two points (perhaps more, but I'm sure he'll point that
out) that Stephen had put into his version with a "?" on them: those
involving doing additional work on canonicalization and cryptographic
transforms.  I think the specs allow us to plug things in here, and
that work on them doesn't need to be explicitly called out in the
charter.  If people disagree, I'm sure they'll say.

Russ: What do you, who will need to approve the charter, think about
this pass?  Do you think it's reasonably solid, and takes into account
the major comments that've been made?  Would you be comfortable with
a working group with this charter?

Everyone: Pretty much the same questions.  Does this reflect what
most of us think?  Does it adequately explain what we're trying to do,
and not trying to do?  And do the milestones seem feasible?


Barry Leiba, Pervasive Computing Technology  

13 Oct 2005

Domain Keys Identified Message (DKIM)

     Russell Housley, Sam Hartman
     Russell Housley <housley(_at_)vigilsec(_dot_)com>
    General Discussion: ietf-dkim(_at_)mipassoc(_dot_)org
    To Subscribe:


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 (and is, in this
context, called "spoofing").

The DKIM working group will produce standards-track specifications that 
allow a domain to take responsibility for having a part in the transmission 
of an email message, using digital signatures, and to publish "policy" 
information about how it uses those signatures.  Taken together, these will 
allow receiving domains to detect (or rule out) spoofing in many 
circumstances.  The specifications will also contain summaries of the 
threats, requirements and limitations that are associated with the specified 

While the techniques specified by this 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.  What to do 
with that information is still left to the receiving domain, and this group 
makes no attempt to define that, or to establish trust relationships, or 
reputation of accreditation systems.

The signatures will use public-key cryptography and will be based on domain 
name identifiers.  Keys will be stored in the responsible identity's DNS 
hierarchy.  The specifications will be based on the following Internet 
* 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.  Because there is significant deployment on the Internet 
of these specifications, as part of the experimentation, the 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 working group will NOT consider related topics, including, but not
limited to, the following:
* Reputation and accreditation systems.  While we expect these to add value
to what is defined by this working group, their development will be 
separate, and is out of scope for this group.
* Message encryption.
* Key management, including key-distribution infrastructure.
* Signatures that are intended to make long-term assertions beyond the 
expected transit time of a message.
* Signatures that attempt to make strong assertions about the identity 
of the message author.
* Duplication of prior work in signed email, incuding S/MIME and OpenPGP.
* Details of user-level signing of messages.  While the specifications may 
allow for extension to user-level signing, this group is specifically aimed 
at the domain level.

Once the primary goals are met, the 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 deliverables for this working group will be
* an informational RFC providing an overview of the area and of DKIM
* an informational RFC presenting a detailed threat analysis of 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

 7/05     Issue initial Internet-Draft[s] of signature specification (done)
11/05     Vancouver BoF
01/06     WG formed
02/06     WG last call on DKIM threats and requirements
05/06     WG last call on DKIM signature specification
07/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

<Prev in Thread] Current Thread [Next in Thread>