Subject: [ietf-dkim] DKIM charter update proposal

From: Barry Leiba <[email-masked]>
Date: Wed, 30 Sep 2009 12:00:55 -0400

Pasted below is my proposal for an updated DKIM WG charter.  Stephen
has reviewed it and agrees, and now it's the working group's turn.

I've kept two of the paragraphs from the original introduction,
changing only the tenses, from things like "will produce" to "has
produced".  I've turned the original deliverables list into a summary
of what's been delivered.  I've put in new deliverables that basically
amount to "advance the two protocols through the standards process, as
appropriate."  And I've left the "this stuff is out of scope" section,
because it's my sense that we still want to stay away from those
items, at least for now.

Please comment on it.  If you like it, please say so.  If you want
changes, please specify, and suggest specific text.  If you don't
care, and just want to get out of here, that's useful input as well.
Let's define a two-week comment period, which we'll extend if
needed... so, comment as soon as possible, and no later than Friday,
16 October.

Barry, as chair

----------------------------------
Domain Keys Identified Mail (dkim)
----------------------------------

 Chairs:
     Stephen Farrell <[email-masked]>
     Barry Leiba <[email-masked]>

 Security Area Directors:
     Tim Polk <[email-masked]>
     Pasi Eronen <[email-masked]>

 Security Area Advisor:
     Pasi Eronen <[email-masked]>

 Mailing Lists:
     General Discussion: [email-masked]
     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 has produced 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.

  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 do
  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
  discuss a reasonable set of possible actions and strategies, and
  analyze their likely effects on attacks and on normal email
  delivery.

  The previously chartered deliverables for the DKIM working group
  have been completed:

  * An informational RFC presenting a detailed threat analysis of,
    and security requirements for, DKIM. (RFC 4686)

  * A standards-track specification for DKIM signature and
    verification. (RFC 4871, updated by RFC 5672)

  * A standards-track specification for DKIM policy handling.
    (RFC 5617)

  * An informational RFC providing an overview of DKIM and how it
    can fit into overall messaging systems, how it relates to other
    IETF message signature technologies, implementation and
    migration considerations, and outlining potential DKIM
    applications and future extensions. (RFC 5585 and
    draft-ietf-dkim-deployment, in its final stages)

  (One previously chartered deliverable, a standards-track
  specification for DKIM DNS Resource Record(s), was dropped by
  agreement between the working group and the Area Directors.)

  The working group is now ready to switch its focus to refining and
  advancing the DKIM protocols.  The current deliverables for the
  DKIM working group are these:

  * Advance the base DKIM protocol (RFC 4871) to Draft Standard.

  * Collect data on the deployment and interoperability of the
    Author Domain Signing Practices protocol (RFC 5617), and
    determine if/when it's ready to advance on the standards track.
    Update it at Proposed Standard or advance it to Draft Standard,
    as appropriate.

  As before, several related topics remain 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 about 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, including S/MIME and
    OpenPGP.
----------------------------------
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 30 Sep 2009 11:24:34 -0600

Barry Leiba wrote:

> Please comment on it.  If you like it, please say so.

I like it.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 30 Sep 2009 13:45:54 -0400

If advancing DKIM/ADSP along the standards heirarchy is all that's on the 
table, I think it should wait.  

Effective rollout of DKIM in large hetrgenous organizations is complex and 
takes time.  I think it's better to pause for a while and give broad 
operational experience more of a chance to exercise what has just been 
standardized.

Scott K

---

From: Franck Martin <[email-masked]>
Date: Thu, 1 Oct 2009 06:01:38 +1200 (FJT)

Seems to me something is missing: gather data to establish if DKIM specifications have in any way alleviated any misuse of the email system, in particular but not limited to spam, phishing attacks and fraud.

----- Original Message -----
From: "Barry Leiba" <[email-masked]>
To: "IETF DKIM WG" <[email-masked]>
Sent: Thursday, 1 October, 2009 4:00:55 AM GMT +12:00 Fiji
Subject: [ietf-dkim] DKIM charter update proposal

Barry, as chair

 Chairs:

 Security Area Directors:

 Security Area Advisor:

 Mailing Lists:

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 30 Sep 2009 14:00:31 -0700

>   spoofing as it pertains to the signing domain.

I suggest replacing the last sentence with something more generic, to avoid the 
debate about how much any of this pertains to spoofing, per se.  Perhaps instead 
have a value proposition statement derived from the one in the Overview abstract:

    These mechanisms permit email receivers to make additional assessments about 
messages.

>   analyze their likely effects on attacks and on normal email

Delete the first sentence, per my concern above.  At the least, the sentence 
appears to be largely redundant with the preceding paragraph's last sentence.

Isn't the second sentence incorrect?  Doesn't DKIM mandate treated a failed 
validation the same as no signature present?

>   agreement between the working group and the Area Directors.)

Do re-charters usually contain all this history?

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html