Subject: Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Oct 2010 14:16:48 -0700

This version consolidates all of the minor corrections submitted to date, as well as the more substantive things that appeared to have consensus.

It did not include the suggestion to add a few points about MUA improvements that would help in the area of DKIM deployment and MLMs.  I'd like to revisit the idea of adding a paragraph or two about this in an informative appendix.  Do the participants feel this would be a bad or dangerous idea?  The main point would be to lobby MUA developers to begin showing the identity authenticated by DKIM (the AUID or the SDID or both), as Daniel suggested.  I think this is probably something we'd like to see in general and this is as good a place as any to say so.

I also did not convert the status from Informational to BCP, and carefully avoided the standard IETF normative words.  There appears to be some dissent about the sum and substance of this document if it were to move to the stronger level.  My perception of the rough consensus is that we do want to make some statements about the issues discussed in the draft.  However, the only truly normative thing upon which we appear to agree is that MLMs should sign their mail.  I would rather we produce this more complete document at a lower status than a one-paragraph BCP saying only that.

Feedback welcome.

-MSK

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

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 05 Oct 2010 12:58:25 +0100

--On 4 October 2010 14:16:48 -0700 "Murray S. Kucherawy" 
<[email-masked]> wrote:

> However, the only truly normative thing upon which we appear to agree is
> that MLMs should sign their mail.  I would rather we produce this more
> complete document at a lower status than a one-paragraph BCP saying only
> that.

Good plan. That would be rather pointless.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: John Levine <[email-masked]>
Date: 5 Oct 2010 20:24:55 -0000

>  My perception of the rough consensus is that we do want to make
> some statements about the issues discussed in the draft.  However,
> the only truly normative thing upon which we appear to agree is that
> MLMs should sign their mail.  I would rather we produce this more
> complete document at a lower status than a one-paragraph BCP saying
> only that.

If we do that, I think that in fairness to people reading it, we
should say explicitly which recommendations are based on practice, and
which are paper designs a/k/a wild guesses.  Unless I've missed some
implementations, we have considerable experience with lists signing,
and some anedotal experience with damage from ADSP, but everything
else falls into the latter category.

I'm also scratching my head about the bits that are intended to help
people work around faulty DKIM implementations.  Are there other IETF
documents that do that?

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Oct 2010 13:29:16 -0700

> -----Original Message-----
> From: John Levine [mailto:[email-masked]]
> Sent: Tuesday, October 05, 2010 1:25 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> Subject: Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
> 

I'm fine with that.  I think I've tried to do that, albeit weakly, using words like "could".  I don't mind being more explicit.

> people work around faulty DKIM implementations.  Are there other IETF

I'll have to re-read it, but no specific "work around" type intent should be there.  I do think, though, that we've mentioned that there are broken implementations and described how they usually work, and I think that's appropriate.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 06 Oct 2010 12:36:07 +0100

On Mon, 04 Oct 2010 22:16:48 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

> This version consolidates all of the minor corrections submitted to  
> date, as well as the more substantive things that appeared to have  
> consensus.

Of the points I raised, I see that 4.3 still contains "the verifier is    
requested to discard the message". It is, of course, the receiver that  
actually does any discarding.

Also, section 5.6 is still entitled "Pros and Cons of Signature Removal",  
and yet the body of that section contains no "Cons".

And also, in 5.7 s/The MLM could re-evaluate exisiting signatures/The MLM  
could re-evaluate existing signatures/.

Evidently, my draft to allow changing the From: has not been incorporated.  
Would it be worthwhile calling a straw poll on that one?

Many of the people opposed to that seem to be imagining that I have  
proposes an obligatory feature for all MLMs, which my draft carefully  
avoided doing. Or they oppose it because then prefer their own pet  
solution, whereas I have proposed an additional tool for use when the pet  
solutions have been ignored.

Also, I am still unaware of any additional security issue raised by my  
proposal which was not already present without it.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Oct 2010 05:23:49 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Lindsey
> Sent: Wednesday, October 06, 2010 4:36 AM
> To: DKIM

I don't agree, at least not in the architecture I have in mind.  The verifier (e.g. a mail plugin of some kind, or an internal function of an MTA) is in a position to conduct rejections as it sits very near the SMTP portion of a delivery.  The receiver, more likely an MUA or such, is less likely to have any direct influence.

> and yet the body of that section contains no "Cons".

The first paragraph describes a "pro" of leaving them in (i.e., enabling preservation of chain of responsibility), and the second describes a "con" (i.e., if that's a goal, now the MLM might have to change its behavior to do so).  The next paragraph describes a "pro" of removing them, etc.

> could re-evaluate existing signatures/.

Fixed for the next version.

> Would it be worthwhile calling a straw poll on that one?

It didn't appear to have the support of rough consensus, so it wasn't included.  You could indeed request such a poll to see if that's changed.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 06 Oct 2010 09:12:25 -0400

On 10/6/2010 8:23 AM, Murray S. Kucherawy wrote:
> I don't agree, at least not in the architecture I have in mind.  The verifier
> (e.g. a mail plugin of some kind, or an internal function of an MTA) is in a
> position to conduct rejections as it sits very near the SMTP portion of a
> delivery.  The receiver, more likely an MUA or such, is less likely to have
> any direct influence.

The verifier might legitimately not be touching the message, nevermind have the
authority to discard the message.  Just as signing can be done by an independent
service that "contracts with" the author, sender or the like, so can verifying.

I suggest saying "the holder of the message is requested to discard it".

> The first paragraph describes a "pro" of leaving them in (i.e., enabling
> preservation of chain of responsibility), and the second describes a "con"
> (i.e., if that's a goal, now the MLM might have to change its behavior to do
> so).  The next paragraph describes a "pro" of removing them, etc.

I'm not a huge fan of having "pro & con" in a title.

Perhaps simply:  "Signature Removal Issues".

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: Wed, 6 Oct 2010 06:49:49 -0700

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Wednesday, October 06, 2010 6:12 AM
> To: Murray S. Kucherawy
> Cc: DKIM

That paragraph now reads:

   Use of restrictive domain policies such as [ADSP] "discardable"
   presents an additional challenge.  In that case, when a message is
   unsigned or the signature can no longer be verified, discarding of
   the message is requested.  There is no exception in the policy for a
   message that may have been altered by an MLM, nor is there a reliable
   way to identify such mail.  Receivers are thus advised to honor the
   policy and disallow the message.

Does that work for people?

> Perhaps simply:  "Signature Removal Issues".

Done.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 07 Oct 2010 11:03:22 +0100

On Wed, 06 Oct 2010 13:23:49 +0100, Murray S. Kucherawy  
<[email-masked]> wrote:

>> From: [email-masked]  
>> [mailto:[email-masked]] On Behalf Of Charles Lindsey
> I don't agree, at least not in the architecture I have in mind.  The  
> verifier (e.g. a mail plugin of some kind, or an internal function of an  
> MTA) is in a position to conduct rejections as it sits very near the  
> SMTP portion of a delivery.  The receiver, more likely an MUA or such,  
> is less likely to have any direct influence.

You can define the architecture so that the discarding is done by (or  
close to) the verifier, or that it is done by a separate agent (the  
"receiver"). I don't mind either way, but you need to be consistent.  
Currently, the wording of 5.10 suggests that you are using the second  
model (the verifier leaves it alone and the receiver looks at the  
verifification results in the A-R header and decides whether or not to  
actually discard).

The change you have made in response to Dave is an improvement (it solves  
my immediate problem), but it still leaves in doubt which of the two  
models you are using.

> preservation of chain of responsibility), and the second describes a  
> "con" (i.e., if that's a goal, now the MLM might have to change its  
> behavior to do so).  The next paragraph describes a "pro" of removing  
> them, etc.

Well the title was "Pros and Cons of ... Removal", so the first paragraph  
is actually a "Con" of removal for the case where a signature might still  
be valid. There is no dispute about that.

And then the second paragraph is a "Pro" for removal in the case where the  
signature has been invalidated.

But what is missing is any "Con" for removal in the invalidated case (e.g.  
keeping it for forensic use). Actually, a suggestion to replace the  
removed signature with an X-Original-Signature would be quite sufficient  
for forensic purposes. Wuld you be willing to add a suggestion to possibly  
do that?

That second paragraph didn't read like a "Con" to me. In fact it seems  
like a further "Pro" insofar as it recommends a "further action" which  
turns out to be

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Oct 2010 13:00:51 -0700

> Sent: Thursday, October 07, 2010 3:03 AM
> To: DKIM

I'll review it.  Really, though, rejection in some form (bounce, drop, spam-folder) can take place at either location, so maybe it's best to fall back to something more generic and say "a module can reject" instead of naming one or the other specifically.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 07 Oct 2010 16:21:50 -0700

On 10/7/2010 1:00 PM, Murray S. Kucherawy wrote:
> so maybe it's best to fall back to something more generic and say "a module can reject" instead of naming one or the other specifically.

+1

d/
-- 

   Dave Crocker