Subject: [ietf-dkim] ISSUE: SSP-02: Discardable inappropriately specifies possible verifier action

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Feb 2008 15:39:28 -0800

It The original protection being sough in RFC 5016 section 5.3 item 4  
was:
--
4.  SSP MUST be able to publish an expectation that a verifiable
     first party DKIM signature should be expected on receipt of a
     message.
--

To support the problem statement in section 3.2:
--
 From a receiver's standpoint, knowing that a domain not only signs
all of its mail, but places a very high value on the receipt of a
valid first party signature from that domain is helpful.
--

The assertion "discardable" will not resolve the declared problem  
without also increasing the chances email with invalid signatures of  
being discarded rather than rejected, or a DSN being generated, even  
when the RFC 2821 FromMail is within the same domain.  In response to  
concerns expressed about the verifier handling implied by the  
"discardable" assertion, by Steve Atkins, an author of a similar draft  
that coined the term:

"Domains that do not [wish] to suffer a reduction in delivery  
integrity are not candidates for use of any variant of SSP (and, as  
such, their needs are out of scope)."

See:
http://mipassoc.org/pipermail/ietf-dkim/2008q1/009390.html
http://tools.ietf.org/html/draft-levine-asp-00

It is far too soon to establish (or even suggest) discarding as a  
handling practice for DKIM signature failures.  Discarding invalid  
signature early on will prolong incompatibility issues.  In this case,  
discarding messages also eliminates evidence of possible criminal  
activity, which is counter to an effort at eliminating this type of  
fraud.

http://tools.ietf.org/html/draft-ietf-dkim-ssp-02
3.3. SSP Record Syntax
...

discardable  All mail from the domain is signed with an Author
   Signature.  Furthermore, if a message arrives without a valid
   Author Signature due to modification in transit, submission via
   a path without access to a signing key, or other reason, the
   domain encourages the recipient(s) to discard it.

   NON-NORMATIVE DISCUSSION:  Sender signing practices of
   "discardable" would be usually inappropriate for domains of end
   users, because of the potential for mailing lists and similar
   agents to modify messages in such a way as to render the
   signature invalid.  Domains sending mail that is expected to
   pass with no significant modification to the recipient, such as
   domains sending only transactional messages, are appropriate
   places to consider the publication of a "discardable" practice.
   See [RFC5016] section 5.3 and Appendix A for further
   discussion.

To eliminate concerns related to possible mishandling of the message  
and to eliminate a reduction in the integrity of delivery assurances,  
the term "discardable" needs to be changed.

Change to or add:

sole:
  All mail from the domain is signed with an intent to
  avoid agents that may damage or remove their signatures.
  Therefore, this domain represents the sole entity assured
  to provide signatures for this domain's messages.

NON-NORMATIVE DISCUSSION:  Sender signing practices of
   "sole" would be usually inappropriate for domains of end
   users, because of the potential for mailing lists and similar
   agents to modify messages in such a way as to render the
   signature invalid.  Domains sending mail that is expected to
   pass with no significant modification to the recipient, such as
   domains sending only transactional messages, are appropriate
   places to consider the publication of a "sole" practice.
   See [RFC5016] section 5.3 and Appendix A for further
   discussion.

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

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Feb 2008 02:33:43 -0500

Doug,

The way I read SSP-02 is that MTA verifiers are no longer in the picture 
but rather MUAs and it is MUAs that would do the DISCARDING:

                             ^^^^^^^^^^^^

As it reads, the recepient(s) A.K.A END USER(S) will do the discarding 
(whatever that means). There is no any semantics in this draft for MTA 
verifier handling, therefore, there are no MTA rejections concerns.

The draft seems to cater to BULKS MAILERS pushing mail pass MTAs with 
the hope the MTA will ignore DKIM processing passing the buck to the MUA 
DKIM market where "DISCARDNG" (Whatever that means) does not play a SMTP 
  rejection/bounce like concept.

-- 
Sincerely

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

Douglas Otis wrote:
> It The original protection being sough in RFC 5016 section 5.3 item 4 was:
> -- 
> "Domains that do not [wish] to suffer a reduction in delivery integrity 
> are not candidates for use of any variant of SSP (and, as such, their 
> needs are out of scope)."
> 
> See:
> activity, which is counter to an effort at eliminating this type of fraud.
> 
> To eliminate concerns related to possible mishandling of the message and 
> to eliminate a reduction in the integrity of delivery assurances, the 
> term "discardable" needs to be changed.
> 
> Change to or add:
> 
> sole:
> NOTE WELL: This list operates according 
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
> 
>

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 12 Feb 2008 17:25:35 +0100

Douglas Otis wrote:

> without also increasing the chances email with invalid signatures  
> of being discarded rather than rejected, or a DSN being generated,
> even when the RFC 2821 FromMail is within the same domain.

The term is MAIL FROM (46 occurences in RFC 4408).  IMO "suspicious"
was better than "discardable".  The 2821bis terms for "discard" is
"drop", adding tons of caveats, without noting non-technical facts,
e.g., "dropping mail" can violate the "constitution" (or base law) 
where I live, and that is not on the same level as ordinary crimes.

If you (not you personally) really must invent a new term instead
of sticking to "suspicious" or simply FAIL (for auth-headers), how
about using "unacceptable" ?  This clearly indicates the receivers
already dropped the ball when they accepted any "unaccptable" mail.

 Frank

---

From: Steve Atkins <[email-masked]>
Date: Tue, 12 Feb 2008 08:57:09 -0800

> already dropped the ball when they accepted any "unaccptable" mail.

That doesn't match the semantics of SSP.

"Discardable" does match the semantics of SSP.

Is the issue that you don't like the semantics SSP implies, or that
you'd prefer we were more circumspect about describing them?
They'd both be valid concerns, but they're quite different.

Cheers,
   Steve

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Feb 2008 12:29:11 -0500

> They'd both be valid concerns, but they're quite different.

It has nothing to do with LIKE or DISLIKE.

It simply doesn't jive with SMTP design. The only entity in email 
framework that can "safely" discard mail without raising technical and 
"legal" eyebrows  are end users.

If your ASP design it to remove all MTA handling considerations from the 
DKIM/SSP mix, then it might make sense.   But it doesn't fit with the 
general case.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Feb 2008 12:30:28 -0500

> already dropped the ball when they accepted any "unaccptable" mail.

+1

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Feb 2008 09:50:45 -0800

On Feb 11, 2008, at 11:33 PM, Hector Santos wrote:

> Doug,
>
> The way I read SSP-02 is that MTA verifiers are no longer in the  
> picture but rather MUAs and it is MUAs that would do the DISCARDING:
>

Apple's dictionary- recipient:
a person or thing that receives or is awarded something

Per the SSP-02 abstract:

DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and
contents of messages by either Mail Transport Agents (MTAs) or Mail
User Agents (MUAs).  The primary DKIM protocol is described in
This document describes the records that authors' domains can use to
advertise their practices regarding signing their outgoing mail, and
how other hosts can access, parse and interpret those records.

Clearly SSP is intended for use by both MUAs and MTAs.  However,
discarding is _not_ appropriate at the MTA in many cases.  Message
handling should be defined by a follow-on document.  One such
document might be written for use at the MTA, and another at the
MUA.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Feb 2008 13:15:01 -0500

> a person or thing that receives or is awarded something

In the SMTP "dictionary",  recipients are RCPT-TO forwarding paths A.K.A 
end users.

> document might be written for use at the MTA, and another at the

Clearly, this is what happens when you have 2+ years of work 
commandeered in less than 2 weeks (admittedly a thing of beauty in the 
art of Mastering Chaos) with essentially a Find/Replace string stripped 
down document (IMO borderline unethical) where you end up with 
conflictive semantics all over the place.

Clearly, the attempt was to remove all MTA verifiers logic for filtering 
DKIM mail with the only explicit semantics provided for a MUA entity.

But you also need to ask, why even have an SSP or ASP "skeleton" 
document? We already have the model of ideas in RFC 4871 and RFC 5016.

At this point, I would vote for a total SSP/ASP abandonment rather than 
risk the email world to such questionable late minute changes without 
thinking much about the consequences.

-- 
Sincerely

Hector Santos, CTO

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 12 Feb 2008 19:45:53 +0100

Steve Atkins wrote:

 [Unacceptable]

> Is the issue that you don't like the semantics SSP implies,
> or that you'd prefer we were more circumspect about
> describing them?

I'm not sure - I just prefer to stay as far as possible away
from "dropping mails" (even if that's what will happen in
practice).  "Rejectable" could be fine, but a dictionary I
use does not recognize "rejectable" as proper English. 

To stay out of trouble FAIL is IMO also fine, but IIRC folks
here did not like FAIL, and they did not like "suspicious". 

>From my POV "discardable" is worse.  Above all receivers have
to follow 2821bis.  SSP does not guarantee that "discardable"
mails match what is specified in 2821bis section 6.2.

 Frank

---

From: Jim Fenton <[email-masked]>
Date: Tue, 12 Feb 2008 11:08:08 -0800

Hector Santos wrote:
> art of Mastering Chaos) with essentially a Find/Replace string 
> stripped down document (IMO borderline unethical) where you end up 
> with conflictive semantics all over the place.
>
> Clearly, the attempt was to remove all MTA verifiers logic for 
> filtering DKIM mail with the only explicit semantics provided for a 
> MUA entity.
>
> At this point, I would vote for a total SSP/ASP abandonment rather 
> than risk the email world to such questionable late minute changes 
> without thinking much about the consequences.

With respect to the process by which we got to ssp-02:

Eric and I (with most of the hard work done by Eric, of course) worked 
on a stripped-down version of SSP in late December and early January 
that we thought was closer to what working group consensus was at the 
time.  We shared this early draft with the Chairs.  I was still 
concerned about making such a sweeping change without specific direction 
from the WG, so on January 25, I sent out a message "A proposal for 
restructuring SSP" in order to socialize the idea.

One of the responses I received was from John Levine, who was editing 
the ASP draft with a number of other people operating outside the 
working group.  We exchanged drafts and found that there were a lot of 
similarities, and (with John's permission) incorporated some of the 
language from that early ASP draft into SSP.  As I remember, Appendix A 
is almost entirely from the ASP draft.

I do think that we took the appropriate steps before introducing what is 
more than an incremental change from the previous draft.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Feb 2008 11:08:42 -0800

> They'd both be valid concerns, but they're quite different.

Your SSP assertion is defined in terms of verifier actions.  Defining  
this action is premature, and in the case of the term "discardable",  
will likely result in often inappropriate actions.  SSP could use the  
term "non-compliant" with an assertion of being the "sole" legitimate  
signer.  Actions should remain within the discretion of the verifier,  
where the state of the assertion is to be judged against compliance  
with the domains assertions.  "Discardable" does not match with this  
semantic as it does not permit an assessment of compliance.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Tue, 12 Feb 2008 14:16:08 -0500 (EST)

> mails match what is specified in 2821bis section 6.2.

One possible deployment of ASP would work like this:

- Have the MTA/Verifier tag "discardable" mail with a hint to the
  recipient.

- Leave the handling of this hint up to recipient preferences.

This does not violate the prime directive of x281, nor does it
force MTA operators to throw away mail, which may be forbidden.

	Wietse

---

From: "Siegel, Ellen" <[email-masked]>
Date: Tue, 12 Feb 2008 14:27:39 -0500

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Douglas Otis
> 

Are we talking about the policy tag value, or the description of email
that does not match the published policy? Perhaps part of the confusion
is that we appear to be using the term "discardable" in both contexts.

"Discardable" as a policy tag value does reflect the author POV. I
understand the concern that we may not want to be advocating actual
discarding of the messages that don't comply with the published author
practice for various reasons... perhaps that could be fixed simply by
updating the description/definition of the "discardable" category,
rather than by searching for an alternate tag value? 

Ellen

---

From: Jim Fenton <[email-masked]>
Date: Tue, 12 Feb 2008 14:18:01 -0800

> already dropped the ball when they accepted any "unaccptable" mail.

I don't want to get into the discussion of the best word to use; for me, 
"aardvark" would be fine.  But this points out what seems to be a 
misunderstanding in SSP-02:  Unlike the output of SSP-01 which was an 
evaluation of the message with respect to SSP, the output of SSP-02 is 
the practice itself.  It's not saying something about the message, it's 
just telling the Evaluator what the practices are.

Although the names don't (or shouldn't) matter, the definition of 
Suspicious in SSP-01 was definitely an evaluation of the message.  
Unacceptable, although I haven't seen a definition for it, gives the 
same sense that it's passing judgment on the message, which is something 
that a great many WG participants had a problem with in SSP-01.

-Jim

---

From: "J D Falk" <[email-masked]>
Date: Tue, 12 Feb 2008 18:03:17 -0500

> that a great many WG participants had a problem with in SSP-01.

*agree*

As I see it, the (informal, colloquial) meaning of "discardable" is "if
the verifier decides to discard un-authenticatable messages, the author
is cool with that."  Words like "unacceptable" or "suspicious," while
probably appropriate to many conversations, would connote a very
different meaning.