Subject: [ietf-dkim] Proposed new charter

From: Barry Leiba <[email-masked]>
Date: Fri, 19 Feb 2010 14:31:56 -0500

Here is a charter proposal for us to bash.  It covers the items we
voted on.  As a working group, we'll need to agree on the wording, and
come up with a few reasonable milestones with dates.

Have at it.

Barry and Stephen, as chairs

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

Description of Working Group:

  +++ Background +++
  Internet mail protocols do not certify the validity of any
  identification information associated with a message, including
  the author's name and address.  This limits the ability to
  determine legitimate accountability for a message.  It also limits
  the ability to determine unauthorized uses of these identifiers.

  The DKIM working group has produced two standards-track
  specifications.  The first allows a domain to take responsibility,
  using digital signatures, for having taken part in the
  transmission of an email message.  The second allows a domain to
  publish information about its practices in applying those
  signatures. Taken together, these allow receiving domains to
  ascertain responsibility for a message, and possibly to detect
  some unauthorized assertions of authorship.

  While the techniques specified by the DKIM working group will not
  prevent fraud or spam, they can assist in efforts to establish a
  basis for identifying actors that can be trusted. 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.

  +++ Previous Work +++
  The previously chartered deliverables for the DKIM working group
  have been completed.  To provide background, we list them here:

  * 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.)

  +++ New Work +++
  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:

  1. Advance the base DKIM protocol (RFC 4871) to Draft Standard.
     This is the first priority for the working group.

  2. Collect data on the deployment, interoperability, and
     effectiveness of the base DKIM protocol, with consideration
     toward updating the working group's informational documents.

  3. Collect data on the deployment, interoperability, and
     effectiveness 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, advance it to
     Draft Standard, deprecate it, or determine another disposition,
     as appropriate.

  4. Taking into account the data collected in (2) and (3), update
     the overview and deployment/operations documents.  These are
     considered living documents, and should be updated periodically,
     as we have more real-world experience.

  5. Consider issues related to mailing lists, beyond what is
     already documented.  This includes considerations for mailing
     list software that supports or intends to support DKIM, as well
     as considerations for DKIM/ADSP deployment in the presence of
     mailing lists that do not have such support.  Include
     recommendations in the informational documents, or produce a
     new informational document about mailing-list considerations.

  +++ What's Out Of Scope +++
  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: John Levine <[email-masked]>
Date: 21 Feb 2010 01:57:50 -0000

>come up with a few reasonable milestones with dates.

It looks good to me, particularly the parts about what we're not
going to do.

I had some interesting conversations about list management at MAAWG,
so when it's time for volunteers, I'll be happy to work on that.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Sun, 21 Feb 2010 07:51:34 -0500

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Barry Leiba
> Sent: Friday, February 19, 2010 2:32 PM
> To: IETF DKIM WG
> Subject: [ietf-dkim] Proposed new charter
> 

It looks good to me. I don't have any input on dates/timeframes at this
point.

Mike

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 22 Feb 2010 12:00:07 +0000

> It looks good to me. I don't have any input on dates/timeframes at this

+1

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 22 Feb 2010 16:19:29 -0500

+1

--
Jeff Macdonald
Ayer, MA

Repopulate Form

---

From: Franck Martin <[email-masked]>
Date: Mon, 22 Feb 2010 14:29:48 -0800 (PST)

it seems point 5 should be extended to "forwarding including mailing lists"

All the rest looks good.

----- Original Message -----
From: "Barry Leiba" <[email-masked]>
To: "IETF DKIM WG" <[email-masked]>
Sent: Friday, 19 February, 2010 11:31:56 AM
Subject: [ietf-dkim] Proposed new charter

Have at it.

  +++ Background +++

  +++ Previous Work +++

  +++ New Work +++

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 23 Feb 2010 09:55:55 +0100

> it seems point 5 should be extended to "forwarding including mailing lists"

What do you mean exactly? Section 3.9.2. of RFC 5321 identifies 
"Lists" as a forwarding technique, contrasted to alias expansion. That 
technique just implies changing the envelope sender, which is fairly 
generic. Point 5 is apparently about full blown mailing lists, which 
also have, e.g., RFC 2369's List-* fields.

IMHO, "forwarding" also includes any instance of mass mailing where 
the list or recipients is expanded on a server. Technically, it is not 
a very precise term... --that's why I'm asking.

> From: "Barry Leiba"<[email-masked]>
>[...]

---

From: Franck Martin <[email-masked]>
Date: Tue, 23 Feb 2010 02:24:48 -0800 (PST)

It seems a .forward or other techniques could break the signature. This could be alleviated by recommending which headers should be signed or not. We had a talk with Barry, John, Dave and others about dkim and forwarding recently. However it seems we lack examples/evidence of broken dkim due to forwarding. We know mailing lists breaks dkim in many conditions, we suspect forwarding may do it too. Let's think about it while we fix mailing list and dkim.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 23 Feb 2010 07:31:11 -0800

On 2/23/2010 2:24 AM, Franck Martin wrote:
> It seems a .forward or other techniques could break the signature. This could
> be alleviated by recommending which headers should be signed or not.

Per the relevant discussion in the email architecture document:

    <http://bbiw.net/specifications/rfc5598-email-arch.html#rfc.section.5.1>

most forwarding as an aliasing function is not likely to break a DKIM sig.

d/

-- 

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 23 Feb 2010 11:42:06 -0800

> Sent: Friday, February 19, 2010 11:32 AM
> To: IETF DKIM WG

+1

---

From: Barry Leiba <[email-masked]>
Date: Tue, 23 Feb 2010 15:40:15 -0500

> come up with a few reasonable milestones with dates.

It's only been a few days, but so far we're getting good agreement on
the charter text, but no milestones and dates.  We'd really like the
working group -- not the chairs -- to decide on the deliverables and
the dates.  If folks are willing to agree to text, but not to be clear
about what we'll produce when, we think that's a sign of insufficient
energy to move forward.

If y'all want to do this, we'll need some proposals for what gets
accomplished and when, so we can discuss that too.

Barry, as chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 23 Feb 2010 13:36:04 -0800

>      This is the first priority for the working group.

Unfortunately I don't have any background doing this kind of work, so I'm forced to guess.  But what about the July IETF as a "done-by" date?  Is that a crazy idea?

>      toward updating the working group's informational documents.

July IETF.

>      Draft Standard, deprecate it, or determine another disposition,

November IETF.

>      as we have more real-world experience.

February 2011 IETF.

>      new informational document about mailing-list considerations.

I think this can be done in parallel, so November IETF.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Feb 2010 07:30:27 +0100

Typically, an interoperability survey is required to go to draft.  
Considering that you may wish to reverse the order a bit.

Eliot

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 24 Feb 2010 11:44:15 +0000

> Considering that you may wish to reverse the order a bit.

If that's the case (being new, I don't know whether it is or not), then 
should the wording be modified to make the interoperability survey a higher 
priority than item 1? That is: the dependencies should be done first, or at 
least made explicit in the charter.

>> Unfortunately I don't have any background doing this kind of work, so
>> I'm forced to guess.  But what about the July IETF as a "done-by" date?
>> Is that a crazy idea?
>>

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Wed, 24 Feb 2010 18:21:00 +0530

I did suggest this at MAAWG - adding that part of this interop
workshop should be between different ISP and/or corporate mailserver
implementations of DKIM

This is so that the interop between in-production DKIM systems can be tested,

This is in addition to testing the interop between the various MTA
reference implementations (an iteration of which was already done some
time back)

-- 
Suresh Ramasubramanian ([email-masked])

---

From: SM <[email-masked]>
Date: Wed, 24 Feb 2010 06:34:00 -0800

>Considering that you may wish to reverse the order a bit.

Yes.

At 13:36 23-02-10, Murray S. Kucherawy wrote:
>Unfortunately I don't have any background doing this kind of work, 
>so I'm forced to guess.  But what about the July IETF as a "done-by" 
>date?  Is that a crazy idea?

The second item (new work) is about collecting data on the 
effectiveness of the protocol.    There is an overlap with item 4.

  1. Collect data on the deployment, interoperability, and effectiveness
     of the base DKIM protocol (RFC 4871) and produce an implementation report.

  2. Advance the base DKIM protocol (RFC 4871) to Draft Standard.
     This is the first priority for the working group.

There should not be significant changes in the specification for such 
a move.  If the Working Group agrees to that, items 1 and 2 can be 
done by July.

At 01:57 24-02-10, Franck Martin wrote:
>Shouldn't we move forward Murray's draft "quickly" that allows to 
>report back broken DKIM signature to the validating domain?

That's on MARF's charter.

Regards,
-sm

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 24 Feb 2010 16:38:14 -0700

+1 on the charter.  As for milestones....

> Unfortunately I don't have any background doing this kind of work, so I'm forced to guess.  But what about the July IETF as a "done-by" date?  Is that a crazy idea?

Same here, but let's try.

>>     toward updating the working group's informational documents.

Perhaps:

2a. Develop a plan to collect data, to discuss at July IETF.  (This plan may include advancing the DKIM reporting drafts.)
2b. Enact plan immediately after July IETF.
2c. Collect lots of data.
2d. Report on results periodically, with final report due by November IETF.

>>     Draft Standard, deprecate it, or determine another disposition,

Possible the same three steps, but agreed that it'll mostly happen after July.

+1

+1

--
J.D. Falk <[email-masked]>
Return Path Inc