Subject: [ietf-dkim] Proposed changes to MLM draft

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 30 Aug 2010 11:03:45 -0700

I'd like some help tackling the next version of the MLM draft.  People seem to have varying ideas about what should be removed and perhaps appear in other documents now.  I need some consensus on a direction in which to proceed.

So can I please get some +1s/-1s on each of the following:

(1) Split the document into three documents: A DKIM MLM BCP that discusses signing and verifying in the context of MLMs with no value-add items addressed, a DKIM MLM Informational that discusses possible value-add enhancements to MLMs in the DKIM world, and a non-WG BCP about mailing lists irrespective of DKIM (Dave's proposal);

(2) Tear out everything having to do with making author signatures survive list relaying, dropping all that text altogether, and instead pointing people at S/MIME or PGP (John's proposal);

(3) Something else (and specify what that might be).

AND...

If you support any of the above, please take a few minutes to include some pointers to what text you want changed/exported and in what way.  Actual diffs would be ideal, but I'll take point-form commentary as well.

AND...

If you advocate for a general MLM BCP, this will be a non-WG document (it's outside of our charter) so I'd love to get some MLM operators and developers involved.  (Maybe this should take place on ietf-822 or maybe on a new non-WG list; suggestions welcome.)  Expressions of interest in that work would be appreciated.  I'll approach the APPS ADs about a venue.

Thanks,
-MSK
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 30 Aug 2010 11:40:48 -0700

On 8/30/2010 11:03 AM, Murray S. Kucherawy wrote:
> I’d like some help tackling the next version of the MLM draft.  People seem to
> have varying ideas about what should be removed and perhaps appear in other
> documents now. I need some consensus on a direction in which to proceed.
>
> (1) Split the document into three documents: A DKIM MLM BCP that discusses
> signing and verifying in the context of MLMs with no value-add items addressed,
> a DKIM MLM Informational that discusses possible value-add enhancements to MLMs
> in the DKIM world, and a non-WG BCP about mailing lists irrespective of DKIM
> (Dave’s proposal);

+1

I'd suggest that the second item actually be a normative specification of 
value-added features.  This requires a change to the charter, and so it would 
have to wait until completing the current charter.

> If you advocate for a general MLM BCP, this will be a non-WG document (it’s
> outside of our charter) so I’d love to get some MLM operators and developers
> involved. (Maybe this should take place on ietf-822 or maybe on a new non-WG
> list; suggestions welcome.) Expressions of interest in that work would be
> appreciated. I’ll approach the APPS ADs about a venue.

+1

d/
-- 

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

---

From: Hector Santos <[email-masked]>
Date: Mon, 30 Aug 2010 15:08:11 -0400

Murray S. Kucherawy wrote:
> (1) Split the document into three documents: A DKIM MLM BCP that 
> discusses signing and verifying in the context of MLMs with no 
> value-add items addressed, a DKIM MLM Informational that 
> discusses possible value-add enhancements to MLMs in the DKIM world, and 
> a non-WG BCP about mailing lists irrespective of DKIM (Dave's proposal);

-1.  Please no more delays! Dave's suggestions are not required to fix 
a problem.  Your MLM is designed to FIX conflicts with current WG 
documents.

> (2) Tear out everything having to do with making author signatures 
> survive list relaying, dropping all that text altogether, and 
> instead pointing people at S/MIME or PGP (John's proposal);

-2. There are two parts to the above:

-1. ADSP guidelines is a required engineering consideration for MLM. 
To remove can create interoperability problems.

-1. Please No more dependencies on other technologies based on highly 
subjective non-scientific presumptions.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 30 Aug 2010 11:42:10 -0700

> -----Original Message-----
> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Monday, August 30, 2010 11:41 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Proposed changes to MLM draft
> 

If it's a minor charter tweak, maybe we could start that process before then?

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 30 Aug 2010 12:19:24 -0700

On 8/30/2010 11:42 AM, Murray S. Kucherawy wrote:
>> value-added features.  This requires a change to the charter, and so it
>> would have to wait until completing the current charter.
>

'minor' and 'charter change' in the same sentence constitute an oxymoron.  it's 
a formal ietf process.

perhaps more importantly, i'll suggest it's a distraction from our current work.

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Aug 2010 11:45:20 -0700

On 08/30/2010 11:03 AM, Murray S. Kucherawy wrote:
> I’d like some help tackling the next version of the MLM draft.  People
> seem to have varying ideas about what should be removed and perhaps
> appear in other documents now. I need some consensus on a direction in
> which to proceed.
>
> discusses signing and verifying in the context of MLMs with no value-add
> items addressed, a DKIM MLM Informational that discusses possible
> value-add enhancements to MLMs in the DKIM world, and a non-WG BCP about
> mailing lists irrespective of DKIM (Dave’s proposal);

-1. Multiple documents just confuse issues, and are a giant pain to
     deal with.

> survive list relaying, dropping all that text altogether, and instead
> pointing people at S/MIME or PGP (John’s proposal);

-1. S/MIME and PGP aren't even vaguely related to DKIM, and we're not in
     any position to know whether S/MIME or PGP are better. We should just
     state the facts and leave it that.

Mike

---

From: Hector Santos <[email-masked]>
Date: Mon, 30 Aug 2010 15:59:38 -0400

Murray S. Kucherawy wrote:
> I'd like some help tackling the next version of the MLM draft.  
> People seem to have varying ideas about what should be removed and 
> perhaps appear in other documents now.  I need some consensus on 
> a direction in which to proceed.

Unfortunately, as it has persistently been the pattern for the last 
what 4-5+ years,

    -1, Policy People or those who value it.
    +1, Non-Policy People or the unrestricted resigner advocates.

Your MLM help correct engineering implementations issues between the 
to groups.

I truly hope your are not force to split your document that minimizes 
the need for Mailing List Software developers to correctly engineer 
their products without producing erroneous DKIM signatures problems 
for members.

For me, MLM has been an rekindled hope to finally add DKIM support to 
the MLS component of our mail framework with some level of engineering 
and RFC standard consistent among three WG documents:

    RFC 4686 - Analysis of Threats Motivating DKIM
    RFC 5016 - Requirements for DKIM Signing Practices Protocol
    RFC 5617 - ADSP

Aren't the chairs or the DKIM ADs concern about these IETF engineering 
conflicts when a MLM is being asked to IGNORE these WG work products?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 30 Aug 2010 13:13:03 -0700

> From: Hector Santos [mailto:[email-masked]]
> Sent: Monday, August 30, 2010 1:00 PM
> To: Murray S. Kucherawy

I don't see how the proposed document split minimizes anything.

There's a legitimate question of whether or not we should try to compel MLM developers to write their code to preserve author signatures.  We can debate that question, but if in the end consensus says it's not a useful goal then we shouldn't bother producing text that says it is.

That's a separate issue from the list signing traffic that goes through it irrespective of author signatures.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 30 Aug 2010 13:13:13 -0700

On 8/30/2010 1:10 PM, Rolf E. Sonneveld wrote:
> can you elaborate on what, in your view, would be part of this normative
> specification?

merely as an example, I'll cite the usage of DKIM for subscription and 
submission validation that has been mentioned a few times.  Formally, using DKIM 
that way is almost certainly a value-added semantic that goes beyond the 
semantics of the DKIM signing specification.  That's ok to do, but requires a 
normative spec to define the behavior and meaning.

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 30 Aug 2010 15:34:33 -0400

>     state the facts and leave it that.

I am happy to just state the facts so long as the facts are, 
approximately, that many MLMs break the signatures on messages they 
resend, that's not a bug, and it is vanishingly unlikely that will ever 
change.

The only reason to mention S/MIME and PGP is to point out that there are 
other crypto standards designed to have more robust signatures, if that's 
what you want.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Mon, 30 Aug 2010 16:46:00 -0400

Murray S. Kucherawy wrote:
> There's a legitimate question of whether or not we should try to 
> compel MLM developers to write their code to preserve author 
> signatures.  We can debate that question, but if in the end consensus 
> says it's not a useful goal then we shouldn't bother producing text 
> that says it is.

> That's a separate issue from the list signing traffic that goes 
> through it irrespective of author signatures.

Once again, the real issue is being pushed and brushed aside regarding 
the developed WG product products:

which 100% relates to the "Question, Debate" to the issues regarding 
signature violations, breaking them and/or preservation.

So what are we really debating?  Should MLM or any DKIM verifier 
ignore theses in the interest of preserving something that is 100% 
known to be fault or violation?

We need to get to the heart of the issue here because its been the 
same conflict for too long.  If POLICY is part of the picture, MLM has 
no choice to support this portion of the DKIM protocol engineering - 
otherwise you have "bugs," incompatibility issues and possible 
accusations of reputation harm by intentional ignoring a IETF produced 
standard that exist 100% design to address this signature violation 
issues.

The only way to remove these BUGS is to get of out the POLICY related 
WG work products.

IMO, while policy is still part of the picture, your MLM draft touches 
base with all the issues. No split is required.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 30 Aug 2010 22:10:03 +0200

Dave,

/rolf

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 30 Aug 2010 22:50:58 +0200

On 08/30/2010 10:13 PM, Dave CROCKER wrote:
> submission validation that has been mentioned a few times.  Formally, 
> using DKIM that way is almost certainly a value-added semantic that 
> goes beyond the semantics of the DKIM signing specification.  That's 
> ok to do, but requires a normative spec to define the behavior and 
> meaning.

Can we say anything normative about subscriptions and submissions when 
the From address (even if DKIM signed- and verified OK) does not 
necessarily say anything about the identity of the sender?

Or, vice versa, can we put more trust/faith in the From address if the 
domain in the From address is equal to the d= domain value?

I assume you mean with subscription and submission validation, the act 
of permitting/denying someone/some address to subscribe or to submit 
mail? If so, that's an action in the category 'authorization' and 
authorization requires authentication as foundation.

Please note: I'm not trying to kick off a complete new discussion, but 
these are real questions that keep me busy. I'd love if the answer to 
the second question would be: "Yes, IF domain part of From address 
equals d= domain value, THEN we can use the From address as 
authentication information", but I believe all discussions on this list 
have not provided a clear "yes" answer to this question.

+1 for taking these items out of the MLM draft and create a separate 
document for them, although I'm not sure it can be normative or just 
informational.

/rolf

P.S. Dave, is it possible to disable greylisting for mipassoc.org or at 
least for contributions to this list? Now we get sometimes a-synchronous 
contributions where the answer precedes the question. (And yes, I hate 
greylisting).
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 30 Aug 2010 17:27:56 -0400

On Mon, Aug 30, 2010 at 2:03 PM, Murray S. Kucherawy <[email-masked]> wrote:
> I’d like some help tackling the next version of the MLM draft.  People seem
> to have varying ideas about what should be removed and perhaps appear in
> other documents now.  I need some consensus on a direction in which to
> proceed.
>
>
>
> signing and verifying in the context of MLMs with no value-add items
> addressed, a DKIM MLM Informational that discusses possible value-add
> enhancements to MLMs in the DKIM world, and a non-WG BCP about mailing lists
> irrespective of DKIM (Dave’s proposal);

-1. Or 0. I'd have to see the resulting docs. Since MLM deal with
individuals, I don't understand how DKIM helps here in terms of
verification. If the goal is to somehow be able to verify users via
DKIM, I don't see how that is MLM specific.

> (2) Tear out everything having to do with making author signatures survive
> list relaying, dropping all that text altogether,

+1 I think. Again, I'd have to see the resulting draft. I'll revisit
this tomorrow and see what it looks like.

> point people at S/MIME or PGP (John’s proposal);

-1. No need to mention it. But I agree with John that if people want
signatures to survive MLM, then DKIM isn't it.

-- 
Jeff Macdonald
Ayer, MA

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 30 Aug 2010 17:05:55 -0400

On Monday, August 30, 2010 02:03:45 pm Murray S. Kucherawy wrote:
> I'd like some help tackling the next version of the MLM draft.  People seem
> enhancements to MLMs in the DKIM world, and a non-WG BCP about mailing
> lists irrespective of DKIM (Dave's proposal);

-1.  I don't think the first part has much value without the second (if I 
understand the split correctly).  

> list relaying, dropping all that text altogether, and instead pointing
> people at S/MIME or PGP (John's proposal);

-1.  While I think it's premature to specify "THE" way to solve such problems, 
I think it's useful to present possibilities for implementers to consider.  I 
don't think redefining the problem so that a class of failures are no longer 
failures is helpful.

> If you support any of the above, please take a few minutes to include some
> pointers to what text you want changed/exported and in what way.  Actual
> diffs would be ideal, but I'll take point-form commentary as well.

I'll try and do this, but not today.

> AND...
> 
> If you advocate for a general MLM BCP, this will be a non-WG document (it's
> outside of our charter) so I'd love to get some MLM operators and
> developers involved.  (Maybe this should take place on ietf-822 or maybe
> on a new non-WG list; suggestions welcome.)  Expressions of interest in
> that work would be appreciated.  I'll approach the APPS ADs about a venue.
> 
> Thanks,
> -MSK

Scott K

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 30 Aug 2010 14:18:47 -0700

On Aug 30, 2010, at 11:03 AM, Murray S. Kucherawy wrote:

> (1) Split the document into three documents: A DKIM MLM BCP that discusses signing and verifying in the context of MLMs with no value-add items addressed, a DKIM MLM Informational that discusses possible value-add enhancements to MLMs in the DKIM world, and a non-WG BCP about mailing lists irrespective of DKIM (Dave’s proposal);
>  
> (2) Tear out everything having to do with making author signatures survive list relaying, dropping all that text altogether, and instead pointing people at S/MIME or PGP (John’s proposal);
>  
> AND…
> If you support any of the above, please take a few minutes to include some pointers to what text you want changed/exported and in what way.  Actual diffs would be ideal, but I’ll take point-form commentary as well.

I was about to give a +1 on option 1, but then I started going through draft-ietf-dkim-mailinglists-02 and trying to figure out which sections would go into each of the new documents.  I don't think they can; both the BCP and the Informational would be incomplete without each other, and even if we ignored that they'd still have to each say a lot of the same things about what DKIM is, what lists are, et cetera.

Where that falls apart is that most of the current document is non-normative, and I'm leaning towards agreeing with the concept of a second document being normative.  So then we could have a document based on the current draft which says, in effect, "here are some ways MLMs break DKIM, and how to avoid them."  One of the "how to avoid them" is to make the MLM fully DKIM-compliant, as described in the new normative document.

So it's still a split, but a different split.

> If you advocate for a general MLM BCP, this will be a non-WG document (it’s outside of our charter) so I’d love to get some MLM operators and developers involved.  (Maybe this should take place on ietf-822 or maybe on a new non-WG list; suggestions welcome.)  Expressions of interest in that work would be appreciated.  I’ll approach the APPS ADs about a venue.

I'll probably participate if it happens, but this feels very likely to get a lot of scope creep from people (perhaps including myself) saying "I wish my MLM had this new feature...."

---

From: Douglas Otis <[email-masked]>
Date: Mon, 30 Aug 2010 15:51:44 -0700

> normative spec to define the behavior and meaning.
It seems this would require a charter change, since DKIM does not 
confirm the identity of the author.  Perhaps subscriptions could include 
an option presented to the subscriber asking how they wish their 
messages to be authenticated, where DKIM signed by domain X might be one 
such option.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 30 Aug 2010 15:54:09 -0700

> subjective non-scientific presumptions.

Agreed.

-Doug

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 31 Aug 2010 11:29:50 +0200

On 08/30/2010 08:03 PM, Murray S. Kucherawy wrote:
>
> I'd like some help tackling the next version of the MLM draft.  People 
> appear in other documents now.  I need some consensus on a direction 
> in which to proceed.
>
> value-add items addressed, a DKIM MLM Informational that discusses 
> possible value-add enhancements to MLMs in the DKIM world, and a 
> non-WG BCP about mailing lists irrespective of DKIM (Dave's proposal);
>

+1, but see my previous message about normative vs informational.

> pointing people at S/MIME or PGP (John's proposal);
>

-1.

Removing signatures/traces because

a) some domains don't know how to use ADSP and/or
b) some assessors don't implement RFC4871 correctly

sounds like a bad idea to me. The best the document can do here, is to 
describe what are the pro's of keeping signatures and what are the pro's 
of removing them, in an operational environment.

> If you support any of the above, please take a few minutes to include 
> some pointers to what text you want changed/exported and in what way.  
> Actual diffs would be ideal, but I'll take point-form commentary as well.
>

I'll try to review the -02 version in the next couple of days.

>
> AND...
>
> If you advocate for a general MLM BCP, this will be a non-WG document 
> (it's outside of our charter) so I'd love to get some MLM operators 
> and developers involved.  (Maybe this should take place on ietf-822 or 
> maybe on a new non-WG list; suggestions welcome.)  Expressions of 
> interest in that work would be appreciated.  I'll approach the APPS 
> ADs about a venue.
>

IMO MLM's need a re-design to bring them in line with today's e-mail 
technologies, but inevitably this will lead to (new) MUA requirements. 
As these things only have a small (or no) DKIM component I fully agree 
to move that work to another list.

/rolf

---

From: Hector Santos <[email-masked]>
Date: Tue, 31 Aug 2010 07:16:53 -0400

Murray S. Kucherawy wrote:
> and developers involved.  (Maybe this should take place on ietf-822 
> or maybe on a new non-WG list; suggestions welcome.)  Expressions 
> of interest in that work would be appreciated.  I'll approach the 
> APPS ADs about a venue.

The DKIM WG charter includes LIST operations support.

  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.

Therefore your MLM would be very appropriate.

Mr. Crocker says this is a distracting from "our current work."  Mr. 
Crocker  should be reminded what is out of scope per the charter:

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

The on-going changes in the DKIM draft standard documentations and 
specification semantics all related to reputation has been a major 
distraction, hindrance and road block in completed chartered goals.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 31 Aug 2010 12:51:49 +0200

On 30/Aug/10 20:03, Murray S. Kucherawy wrote:
> non-WG BCP about mailing lists irrespective of DKIM (Dave’s proposal);

-1, splitting the document should only occur as an author's decision
   about topics unrelated to one another.  If the doc contains any
   normative text, then it should go for standard track.  For clarity,
   it should be enough to mark which sections of the document are
   normative and which ones are only informative, as other docs do
   (for one, http://tools.ietf.org/html/draft-moriarty-post-inch-rid).

> pointing people at S/MIME or PGP (John’s proposal);

-1, this topic may need further discussion.  Attribution of
   responsibility for a message destined to _public_ MLMs is
   particularly delicate, given possible replay attacks and FBLs.

   While PGP and S/MIME are fine, they imply signers should abstain
   from signing mail for MLMs.  Is that what we want to recommend?
   Two techniques have been proposed for enabling signers to limit the
   extent of responsibility they take, joint signatures and From-%-
   rewriting; did we reach any conclusion about them?  Are there more?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Daniel Black <[email-masked]>
Date: Tue, 31 Aug 2010 15:03:10 +1000

> lists irrespective of DKIM (Dave's proposal);

-1. A single document is good for implementors.

> people at S/MIME or PGP (John's proposal);

-1. Surviving signatures seems like a good long term goal.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 31 Aug 2010 09:40:44 -0400

So many choices, so little time.....

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Murray S. Kucherawy
> Sent: Monday, August 30, 2010 2:04 PM
> To: [email-masked]
> Subject: [ietf-dkim] Proposed changes to MLM draft
>
>  
>
seem
> (1) Split the document into three documents: A DKIM MLM BCP that
discusses
> enhancements to MLMs in the DKIM world, and a non-WG BCP about mailing
lists
> irrespective of DKIM (Dave's proposal);
>

-1 Do we need as many documents to describe the tail as we need to
describe the dog?
 
> (2) Tear out everything having to do with making author signatures
survive
> people at S/MIME or PGP (John's proposal);

-1 John's proposal is that we leave MLMs alone to do their thing, but in
such a way that it is codified in the working group document. He has
inserted himself into this process in a manner similar to what he did to
ADSP. If we are seriously going to consider tearing out everything
having to do with making author signatures survive list relaying then I
think another  option should be considered - The working group should
drop any attempt to write a document specific to MLMs. Some will operate
in a way compatible with DKIM and others will choose not to.

S/MIME and PGP are out of scope for the working group. It would be
ironic for the DKIM working group to point people somewhere else. It is
essentially an acknowledgement that DKIM is a failure in that the
working group would be expressing a belief that it is not possible for
signatures to survive MLM handling under any circumstances. If it is
possible for DKIM signatures to survive then why the opposition to
documenting such implementations.... could it be potential pressure to
change and evolve? Darwin was right.... evolve or die.
 
> (3) Something else (and specify what that might be).

Drop the effort to write a document specific to MLMs and leave each one
to sink or swim on their own decisions.... 
> If you support any of the above, please take a few minutes to include
some
> If you advocate for a general MLM BCP, this will be a non-WG document
(it's
> outside of our charter) so I'd love to get some MLM operators and
developers
> involved.  (Maybe this should take place on ietf-822 or maybe on a new
> non-WG list; suggestions welcome.)  Expressions of interest in that
work
> would be appreciated.  I'll approach the APPS ADs about a venue.
>
>  
>
> Thanks,
>
> -MSK
>

---

From: Hector Santos <[email-masked]>
Date: Tue, 31 Aug 2010 14:55:14 -0400

> in a way compatible with DKIM and others will choose not to.

This whole IETF process reminds me of the Devil's Advocate quote for 
God's greatest goof of all time:

   "Look but don't touch, Touch but don't taste, Taste but don't swallow"

We allowed informational status documents to alter the draft 
standards, allowing for out of scope goals to be injected, change the 
scope of author domain messages, implicitly begin state to ignore 
draft standards and then needed another informational status document 
to make the corrections to the informational document and also draft 
standards.

Talking about common sense engineering goofs!

The big elephant in the room is unrestricted resigners. The documents, 
proposed standard and/or informational are in conflict with dealing 
with that issue.