Subject: [ietf-dkim] How SSP will assist DKIM-BASE

From: Hector Santos <[email-masked]>
Date: Fri, 14 Dec 2007 11:40:47 -0500

A few years ago I illustrated the boundary conditions of DKIM-BASE and 
how SSP-00 policies were applicable.

With SSP-01, I updated the boundary conditions to reflect to current 
DKIM-BASE protocol consistency model.

Legend:

SSP-01 Policies:

     DKIM=unknown      (Signature Optional
     DKIM=all          (Signature Required, Any party)
     DKIM=strict       (Signature Required, 1st party only)

DKIM-BASE Verify Results:

NONE     - No signature in mail
PASS     - Good Signature, Original Address Signer
PASS 3P3 - Good Signature, 3rd party Signer
FAIL     - Bad Signature, Original Address Signer
FAIL 3P3 - Bad Signature, 3rd party Signer

Table 1.0 - DKIM Verification States illustrates all possible
             outcomes for signature verification against SSP.

                +----------------------------+
                |   Sender Signing Policy    |
    +-----------+----------------------------|
    | DKIM-BASE |         |        |         |
    | RESULT    | UNKNOWN |  ALL   | STRICT  |
    +========================================+
    | NONE      |  +1     |   -1   |   -1    |
    |-----------+---------+--------+---------+
    | PASS      |  +1     |   +1   |   +1    |
    |-----------+---------+--------+---------+
    | PASS 3PS  |  +1     |   +1   |   -1    |
    |-----------+---------+--------+---------+
    | FAIL      |  ?      |   ?    |   ?     |
    |-----------+---------+--------+---------+
    | FAIL 3PS  |  ?      |   ?    |   -1    |
    +-----------------------------------------

The following nomenclature was used to represent the result of each state:

    +1  -> 0% false positive non-repudiated state
    -1  -> 0% false positive non-repudiated state
     ?  -> Something Failed - Indeterminate

How a system reacts is implementation and local policy based.

However, in order to fundamentally analyze the consistency of the 
DKIM-BASE protocol, we need to recognize the known set of boundary 
conditions based on the DKIM-BASE specifications.  There are only five 
possible outcomes for DKIM-BASE:  none, pass, fail and 1st party and 3rd 
party versions of pass and fail.

These can not be escaped as they all present the real possibilities for 
DKIM-BASE outcomes.

As part of the non-repudiation process, the verifier must be aware of 
the true non-repudiated expected conditions by the domain DKIM-BASE 
signature or lack of one.

Therefore given the possible boundary conditions that may exist, the
above chart represents the non-repudiated or repudiated states based on 
the SSP-01 policies of UNKNOWN, ALL and STRICT.

The +/- 1 states are 100% protocol and non-repudiation consistent and
will eliminate a vast major of the current security threats.

Why is there failures?

There are million reasons.  Body and/or Header integrity munging is one. 
Overall, the signature has failed.

I am of the opinion, other layers (such as A/R considerations) may
assist in determining the final outcome.

Some may desire, as in the strict case, that a FAIL should also be
non-repudiated with a -1 outcome, or as well in the ALL case, for a 1st
party signature, a fail should be non-repudiated condition.  The
proposed handling= can assist this determination if so desired by the
domain.

But overall, I hope this analysis shows that there is no reputation 
here.  It is purely 100% focusing on protocol consistency to illustrate 
the importance of SSP in assisting in the non-repudiation process.

Finally, the table also shows how the "bad guys" can exploit the failure 
states.  If verifiers have no guidance, this can promote this type of 
abuse where FAILURE is forced by the bad guys.

One of the reasons I have a problem with the DKIM-BASE inherent policy of:

          "Invalid signature must be viewed as unsigned"

is because it can create false positives/negatives.

If inherent DKIM-BASE mandate is followed, then these indeterminate 
states fold into the DKIM-BASE NONE state which you can see above has an 
unrealistic +1 outcome for an UNKNOWN policy and a -1 for the ALL and 
STRICT policies.

-- 
Sincerely

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

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 14 Dec 2007 20:20:11 +0100

Hector Santos wrote:

> There are only five possible outcomes for DKIM-BASE:  none, pass,
> fail and 1st party and 3rd party versions of pass and fail.

I'm not aware of any FAIL in DKIM, or rather it's by definition
the same as NONE, isn't it ?  Like SPF NEUTRAL is by definition
the same as SPF NONE.

That would simplify your table to three rows.  You could add
the "process" vs. "deny" business resulting in more columns (?)

Talking about "0% false positive" in conjunction with the "1st
author" approach is utter dubious, but I guess I mentioned this
already in the last years ;-) 

> I hope this analysis shows that there is no reputation here.

You could use reputation to decide what "+1" actually means,
e.g. "spammer managed to get SSP right", or to decide if you
wish to evaluate SSP at all.  Or you could decide to ignore
DKIM if there's no chance to get a "-1", IIRC you wanted to
use SSP always *before* checking DKIM, or did you drop that ?

 Frank

---

From: Hector Santos <[email-masked]>
Date: Fri, 14 Dec 2007 14:54:07 -0500

Frank Ellermann wrote:
> the same as NONE, isn't it ?  

That's correct. See the entire message.  I broke it up so you can see 
the difference.

> the "process" vs. "deny" business resulting in more columns (?)

If you fold them, then you a complex situation where you can't repudiate 
a DKIM-BASE policy.

For example, for strict or all policy

   Scenario #1  Mail is really really NOT signed.
   Scenario #2  Mail is signed by invalid

In scenario #1, you have a 100% zero false positive of non-repudiation. 
  It is a condition that everyone agrees is invalid. No one can 
repudiate this.

In scenario #2, if you fold this into a NONE signature, then you do not 
have a zero false positive situation because the reality was "altered" 
from the fact there was an real attempt at a signature process - but 
some reason it failed.  The only way to deal with this deterministically 
is with handling=process or handling=deny.

So in effect, there is a "conflict" with handling= and the DKIM-BASE 
inherent policy of promoting dead signatures to NONE.

> already in the last years ;-) 

I think if you keep "reputation" out of this, then you can better see 
it.  This analysis applies to blind to the good or bad. We all must play 
on the same field first.

> use SSP always *before* checking DKIM, or did you drop that ?

Its a protocol consistency modeling analysis. You have to establish your 
boundary conditions before you can even try to simulate real world 
behavior.  It is DKIM-BASE that defines the conditions and rules of the 
game.  SSP is just the "referee" :-)

-- 
Sincerely

Hector Santos, CTO

---

From: <[email-masked]>
Date: Fri, 14 Dec 2007 17:58:08 -0500

Hector,
The boundary conditions outlined are good but treating broken=unsigned is best case description of a failure. It gives the receiver knowledge and weight without mandating a practice.
thanks,
Bill Oxley

-----Original Message-----
From: [email-masked] on behalf of Hector Santos
Sent: Fri 12/14/2007 11:40 AM
To: [email-masked]
Subject: [ietf-dkim] How SSP will assist DKIM-BASE

Legend:

SSP-01 Policies:

Why is there failures?

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Fri, 14 Dec 2007 18:55:51 -0500

The problem I have is that folding of FAIL to NONE when the policy is
ALL.

If there was "truly" no signature, then this can be repudiated with a
DKIM=ALL.  All parties (signer and receiver) agrees what is known to be 
true.

However, if there is a failure, like in a Mailing List environment or 
ESP for a domain using DKIM=ALL, then we have false positive situations. 
  DKIM can be repudiated.  If we fold this failure to none, then someone 
is not going to be happy.

Of course, if this is what the domain owner wanted, then we are all 
satisfied.   If this is not want the domain wanted, then he really 
shouldn't be using a DKIM=ALL policy.  This can only be valid if there 
is a special relationship between the domain, the signer and the receiver.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Fri, 14 Dec 2007 16:48:33 -0800

Hector,

This breakdown provides only limited value for assessing benefits, and  
nothing in terms of creating a specification.  A specification should  
not attempt to dictate message disposition weighting.  Nevertheless,  
this breakdown should be adjusted to recognize that an invalid  
signature is equivalent to no signature per the specification.  The  
"on-behalf-of" should not matter as well.  Verifiers should retain  
domain histories to assign a domain weight.  Domain weights might  
range from -4 to +4, for example.  So this provides:

  NONE	   - No or invalid signature
  VSOBHOF   - Valid Signature "on-behalf-of" From
  VSOBHOO   - Valid Signature "on-behalf-of" Other than From (g=*)
  TPS	   - Valid third-party signature

           +----------------------------+
           |     Policy Assertions      |
+---------+----------------------------+
| STATE   | UNKNOWN |  ALL   | STRICT  |
+======================================+
| NONE    |   NC    |   AIS  |   SIS   |
|---------+---------+--------+---------+
| VSOBHOF |   DR    |   DR   |   DR    |
|---------+---------+--------+---------+
| VSOBHOO |   DR    |   DR   |   DR    |
|---------+---------+--------+---------+
| TPS     |   TPDR  | ATPDR  |  STPDR  |
|---------+---------+--------+---------+
	
Category 	Disposition
  NC	- no change
  DR	- relative to signing domain
  TPDR	- relative to third-party signing domain
  AIS	- "all" with invalid signature
  SIS	- "strict" with invalid signature
  ATPDR	- relative to "all" with third-party signature
  STPDR  - relative to "strict" with third-party signature

  Disposition Weights
  NC	- 0
  DR	- (OF or OO) domain +2
  TPDR	- third-party domain +1
  AIS	- -2
  SIS	- -3
  ATPDR	- third-party domain
  STPDR  - third-party domain -1

Dropping "strict" and just using first-party domains regardless of  
which header the signature was "on-behalf-of" provides:

FDS	- From domain signature

           +-------------------+
           | Policy Assertions |
+---------+-------------------+
| STATE   | UNKNOWN |   ALL   |
+=============================+
| NONE    |   NC    |   AIS   |
|---------+---------+---------+
| FDS     |   DR    |   DR    |
|---------+---------+---------+
| TPS     |   TPDR  |   ATPDR |
|---------+---------+---------+

Category 	Disposition
  NC	- no change
  DR	- relative to signing domain
  TPDR	- relative to third-party signing domain
  AIS	- "all" with invalid signature
  ATPDR	- relative to "all" with third-party signature

  Disposition Weights

  NC	- 0
  DR	- domain +2
  TPDR	- third-party domain +1
  AIS	- -1
  ATPDR	- third-party domain

-Doug

---

From: Hector Santos <[email-masked]>
Date: Fri, 14 Dec 2007 21:15:37 -0500

Douglas Otis wrote:
> nothing in terms of creating a specification.  

I believe it does.

> A specification should 
> not attempt to dictate message disposition weighting.  

This analysis does not.

> Nevertheless, 
> this breakdown should be adjusted to recognize that an invalid signature 
> is equivalent to no signature per the specification. 

It did.  Read the message again.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Sat, 15 Dec 2007 01:51:47 -0500

Hector Santos wrote:

>> Nevertheless, this breakdown should be adjusted to recognize that an 
>> invalid signature is equivalent to no signature per the specification. 
> 

More to the point Doug.  The reason I showed it separate was to 
illustrate there is a high confidence validation (non-repudiation) when 
there a true no signature state versus the condition where the state is 
artificially altered from a failed signature to non signature.  The 
later introduces less confidence where the former yields full 
confidence.  When you fold it, you have false positives. In short, it 
makes the ALL and STRICT policies less reliable. It weakens the policy.

Does that make sense?

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Mon, 17 Dec 2007 11:01:18 -0800

On Dec 14, 2007, at 10:51 PM, Hector Santos wrote:

> Hector Santos wrote:
>
>>> Nevertheless, this breakdown should be adjusted to recognize that  
>>> an invalid signature is equivalent to no signature per the  
>>> specification.
> illustrate there is a high confidence validation (non-repudiation)  
> when there a true no signature state versus the condition where the  
> state is artificially altered from a failed signature to non  
> signature.  The later introduces less confidence where the former  
> yields full confidence.  When you fold it, you have false positives.  
> In short, it makes the ALL and STRICT policies less reliable. It  
> weakens the policy.
>
> Does that make sense?

Neither an "invalid signature" nor "no signature" offers a safe or any  
significant difference for non-repudiation.  Your assumption appears  
based upon a invalid signature offering greater confidence in a  
message source than would no signature.  Giving a message with a  
broken signature credit is a dangerous policy.  Nevertheless, this  
view seems supported by RFC 4781 section 4.2 Interpretation states:  
"Signers SHOULD NOT remove any DKIM-Signature header fields from  
messages they are signing, even if they know that the signatures  
cannot be verified."

Section 4.2 is not clear that this prohibition on signature removal is  
to be for issuing a "different" message from the one originally  
signed.  In addition, there are cases where a From email-address might  
legitimately appear in a message which is either not signed, or signed  
by a different domain.  There is a practical aspect in regard to  
credits and the potential for abuse as well.

When initially structured to give messages with bogus signatures  
credit, this ensures DKIM will be abused in this manner.  Removing  
invalid signatures avoids being seen as a domain that "intentionally"  
produces invalid signatures, and being categorized as a domain issuing  
"bogus" DKIM signatures.  Protecting resources needed to validate DKIM  
signatures will likely need to avoid sources producing "bogus"  
signatures.  If this comes to pass, then Section 4.2 of RFC4781 would  
be offering fairly poor advice.  The mistake of giving credit to  
invalid signatures ensures why not removing invalid signatures is  
ultimately bad advice.  Giving _any_ credit for an invalid or bogus  
signature ensures a method for abuse. : (

-Doug

---

From: Hector Santos <[email-masked]>
Date: Tue, 18 Dec 2007 12:58:55 -0500

Douglas Otis wrote:

> based upon a invalid signature offering greater confidence in a message 
> source than would no signature.  

On the contrary, less confidence on what a true NO signature condition 
provides.  IOW, by lumping a broken signature, promoted to no signature 
status, then you have what you say is true.  So its not giving it more 
confidence, but rather it us removing confidence away from the 100% 
assurance and benefits the ALL and STRICT policy provides.

David wanted to see the threats and issues of SSP policies.  IMO, this 
is one of them.

> Giving a message with a broken signature credit is a dangerous policy.  

True.  But giving it credit wasn't the point here.

> to be for issuing a "different" message from the one originally signed.  

Well, according to,

   http://www.ijs.si/software/amavisd/amavisd-new-docs.html#dkim

Mailman is already stripping and replacing signatures:

   "A representative of another type of mailing lists
    is Mailman, which often modifies mail body and strips out
    original signatures, unless explicitly configured not to."

-- 
Sincerely

Hector Santos, CTO

---

From: Damon <[email-masked]>
Date: Tue, 18 Dec 2007 13:10:14 -0500

Sincerely

Hector Santos, CTO

+1 This is something that we have been hashing out for a while but for
some reason we are still trying to sneak through this verbiage. I
believe there is a huge difference between broken and no signature and
that this difference MUST be preserved.

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Dec 2007 11:19:28 -0800

On Dec 18, 2007, at 9:58 AM, Hector Santos wrote:

> Douglas Otis wrote:
>
>> Neither an "invalid signature" nor "no signature" offers a safe or  
>> any significant difference for non-repudiation.  Your assumption  
>> appears based upon a invalid signature offering greater confidence  
>> in a message source than would no signature.
>
> On the contrary, less confidence on what a true NO signature  
> condition provides.

This dubious strategy provides a significant incentive for bad actors  
to insert "bogus" DKIM signatures.

Would it matter whether the signature hash is valid, but the signature  
is not?

Would it matter whether the hash is wrong, but the signature matches  
with the invalid hash?

What level of forensics should invalid signatures entail?

What is reasonable to expect of a DKIM verifier's resources?

> IOW, by lumping a broken signature, promoted to no signature status,  
> then you have what you say is true.

This still gives credit to an invalid signature which might be for  
lying.  Lying is already being abused.

The fallout of giving credit for lying would be to accelerate a need  
for DKIM resource triage.  Any domain found emitting invalid  
signatures is likely to be identified as wasting these DKIM  
resources.  The vast majority of messages are undesired, where DKIM  
already affords signers a sizeable advantage over that of verifiers.

Signing a message requires a one-time effort which can be disseminated  
many fold.  Add to this, an influx created by giving partial credit to  
bogus DKIM signatures.  In all likelihood, when confronting rampant  
bogus signature abuse, _any_ source found emitting invalid signatures  
may find their messages blocked, or at least excluded from a DKIM  
validation process.

The only way to ensure DKIM signatures are not abused requires NOT  
giving _invalid_ signatures _any_ credit over that of _no_  
signatures.  The base draft specifically declares "no" signature is  
equivalent to "invalid" signatures.  A means to ensure your outbound  
MTA is not seen as producing "bogus" signatures requires removal of  
known invalid signatures.  This mode of protection therefore means  
advice given in the DKIM base specifications regarding interpretation  
are ill-considered.  Some like to learn the hard way.

> So its not giving it more confidence, but rather it us removing  
> confidence away from the 100% assurance and benefits the ALL and  
> STRICT policy provides.

This is just semantics.  Any added weight for bogus signatures _will_  
be abused.

> David wanted to see the threats and issues of SSP policies.  IMO,  
> this is one of them.

We agree, but for entirely different reasons.

> True.  But giving it credit wasn't the point here.

Sigh.

>> Section 4.2 is not clear that this prohibition on signature removal  
>> is to be for issuing a "different" message from the one originally  
>> signed.
>
> Well, according to,
>

Mailman then has an extremely good default.  A strategy that gives  
credit to bogus signatures spells disaster.  Signers therefore should  
be prepared for the fallout created by ill-considered strategies.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 19 Dec 2007 10:24:23 -0000

On Tue, 18 Dec 2007 19:19:28 -0000, Douglas Otis <[email-masked]>  
wrote:

>> provides.
> This dubious strategy provides a significant incentive for bad actors to  
> insert "bogus" DKIM signatures.
>

That is a matter for the verifier to decide. It is none of our business.

If a verifier believes he can give a better service to his clients (less  
false positives, perhaps) by distinguishing whether the failure was in the  
body hash or in the header hash, or even by trying to reverse engineer the  
changes that had caused the previously good signature to become bad, then  
he is welcome to try.

> giving _invalid_ signatures _any_ credit over that of _no_ signatures.   
> The base draft specifically declares "no" signature is equivalent to  
> "invalid" signatures.  A means to ensure your outbound MTA is not seen  
> as producing "bogus" signatures requires removal of known invalid  
> signatures.  This mode of protection therefore means advice given in the  
> DKIM base specifications regarding interpretation are ill-considered.   
> Some like to learn the hard way.

-1 (or even -99)

-- 
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: [email-masked] (Wietse Venema)
Date: Wed, 19 Dec 2007 09:55:42 -0500 (EST)

Is no signature equivalent to a bad signature?

Is a bad signature the result of malice or accident?

Some don't distinguish between these cases, arguing that favoring
bad signatures over no signatures only encourages criminals to send
mail with bad signatures.  For example:

> insert "bogus" DKIM signatures.

Others believe that they can distinguish between malice and accident.
For example:

> changes that had caused the previously good signature to become bad, then  

Now consider the case that you can't reverse engineer the damage.
At this point you can't distinguish between malice or accident.

Will you give "no signature" equal treatment to "bad signature",
or will you give mail with bad signatures (such as a valid header
that was pasted on top of a forged body) more favorable treatment?

	Wietse

---

From: <[email-masked]>
Date: Wed, 19 Dec 2007 10:14:27 -0500

I would assume that a valid unbroken signature would be reputation
checked and lightly filtered
Where a broken or no signature would get full scrutiny by all the tools
at my site.
That is the easiest way (for me) to handle the message flow
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wietse Venema
Sent: Wednesday, December 19, 2007 9:56 AM
To: [email-masked]
Subject: [ietf-dkim] Accidental versus malicous error (was: SSP assist
DKIM)

> This dubious strategy provides a significant incentive for bad actors
to  

	Wietse

---

From: Damon <[email-masked]>
Date: Wed, 19 Dec 2007 13:06:24 -0500

As an operations person, I imagine that I would have a type of
double-check. I certainly would be monitoring how many good signatures
that I would be getting from sources that sign. If suddenly my average
good sign for a particular site went down and my average bad sign went
up, it would cause me to take notice and have a look.

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Dec 2007 21:35:51 -0800

On Dec 19, 2007, at 10:06 AM, Damon wrote:

> double-check. I certainly would be monitoring how many good  
> signatures that I would be getting from sources that sign. If  
> suddenly my average good sign for a particular site went down and my  
> average bad sign went up, it would cause me to take notice and have  
> a look.

In other words, you would pay attention to bogus DKIM signatures that  
are wasting resources and perhaps representing an excess of spam.   
Wouldn't you then also pay attention to which SMTP clients gave you  
the highest number of invalid DKIM signatures?  Would your filter give  
credit to a message for including an invalid signature?

Once SMTP clients find they might be blocked for having issued too  
many invalid DKIM signatures, they might remove invalid DKIM  
signatures beforehand.  Although this is in conflict with the base  
specification, at least this measure ensures SMTP clients are not  
associated with bad behaviours related to bogus DKIM signatures.

If, or when, DKIM signature hygiene does becomes a common practice, as  
perhaps it should, then any invalid DKIM signature would be fairly  
indicative of either older systems already listed as being DKIM  
unfriendly, or newer and perhaps questionable systems behaving badly.   
Weighing an invalid DKIM signature as 'implying' a message is likely  
to have originated from some domain invites bad behaviour that wastes  
valuable resources.   Although an invalid signature should be  
considered equal to no signature (as also specified in the base  
specification), from the responses on this list, expect many will bet  
on initial statistics and get this wrong.  This does not bode well,  
and could represent a sizeable loss of receiver resources.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 20 Dec 2007 10:38:48 -0000

> that was pasted on top of a forged body) more favorable treatment?

That is a matter for each verifier to decide. Over time, many ingenious  
strategies for distinguishing the scams from the accidents may be devised,  
and we should welcome that. The examples I gave merely indicated a few of  
the possibilities.

---

From: Damon <[email-masked]>
Date: Thu, 20 Dec 2007 12:29:14 -0500

Although an invalid signature should be
> -Doug

I do not see this as being correct and I never agreed with it.
I am going to have to do "something" whether the signature is broken
or not. Just because messages have broken signatures does not mean
that I am going to have to add even 1 more linux server to my farm to
handle them. My disagreement comes with the difference between ALL and
STRICT. ALL would mean that all of my messages are signed, broken or
not. Any message coming from me with NO signature is a failure of my
published policy. When I receive a message from this domain I will
likely accept the message if it has a signature regardless of the
validity and drop the messages with no signature on the floor. At this
point I have not determined the validity of the signature just that
one existed or didn't. Next I would run through the checks. If I
determine that the signature is invalid, by having it promoted/demoted
to "no signature" I should be able to drop it on the floor. This is a
BAD idea and is not something I would like to promote as this action
just removed the difference between ALL and STRICT and now everything
is STRICT. What I do with a message that has a broken signature and
the policy for the domain is ALL is up to me. It will likely go
through rigorous testing- but that is none of your/our business and I
believe that forcing the operational folks into this sort of corner is
not something that we should be doing.

Regards,
Damon Sauer

---

From: Hector Santos <[email-masked]>
Date: Thu, 20 Dec 2007 13:30:55 -0500

Douglas Otis wrote:

> Once SMTP clients find they might be blocked for having issued too many 
> invalid DKIM signatures, they might remove invalid DKIM signatures 
> beforehand.  Although this is in conflict with the base specification, 
> at least this measure ensures SMTP clients are not associated with bad 
> behaviours related to bogus DKIM signatures.

Not so.

If the SMTP client is going to strip signatures, then the verifier is 
now in the 100% non-repudiated state of NO signature and will label the 
message SUSPICIOUS for DKIM=ALL/STRICT policies.

The question is how or when can this happen.

Well, of course, this is not an original source because if a SMTP client 
is seeing bad signatures, you are assuming it itself did not honor 
DKIM-BASE or SSP when it first received the message and decided to 
redistribute or relay the mail.

So all you really highlighting here is the need for the middle ware to 
be protocol consistent as well.

For example, if Mailman is ignorant of SSP and the domain's strict 
policy, and it strips the signatures, then the final verifier will have 
no problem marking this transaction as SUSPICIOUS per SSP-01.

On the other hand, if Mailman left it alone, the verifier will be left 
in a limbo state which can only be rectified with a HARD requirement 
that STRICT means STRICT and broken also means the message is 
SUSPICIOUS.  DKIM-BASE will justified this hard SSP requirement because 
of its broken to no-signature promotion mandate.

> unfriendly, or newer and perhaps questionable systems behaving badly.  

So who is at fault here?

1) The user who didn't follow company policy and use a
    company property outside its business interest?

2) Mailman or any other similar middle-ware who may not be
    DKIM and/or DKIM/SSP compliant and allowed the user
    to submit unauthorized messages?

3) Mailman or any other similar middleware who will strip
    and/or strip/replace a redistribution because it has
    altered the mail integrity?

> Weighing an invalid DKIM signature as 'implying' a message is likely to 
> have originated from some domain invites bad behaviour that wastes 
> valuable resources.  

No dispute there. I always said that.

> Although an invalid signature should be considered 
> equal to no signature (as also specified in the base specification), 
> from the responses on this list, expect many will bet on initial 
> statistics and get this wrong.  

I find this funny because I do seem to recall that you and others were 
against restrictive policies because it was believe will restrict and 
promote false positives in valid roaming users situations.

The problem as I see it that these same people did not want to give SSP 
the light of day in lieu of using A/R heuristics to address the issue of 
valid vs broken signatures.

 > This does not bode well, and could
> represent a sizeable loss of receiver resources.

Your point is clear and for me, it was well long understood as a problem.

But you need to see SSP is not the problem here.  It is DKIM-BASE with 
its broken signature semantics.   SSP is fine when following the 
DKIM-BASE broken signature to No Signature status. But you do introduce 
FALSE POSITIVES into SSP because of it.   As the SSP boundary table 
showed, the GREY area is when the signature is DKIM-BASE signature is 
truly broken.

These can be a GOOD or BAD intention message.

Some systems may want to take the high road and clearly label these as 
bad and outright reject them and it will justified by the DKIM-BASE bad 
to no signature mandate.

Some system may just wish to pass it on to a A/R concept.

Some system may just REJECT them for a TRUE no signature, and pass on 
the bad signature to a A/R concept to learn more about it.

The problem is this:

Talking for myself here,  I don't want to implement something that will 
have a history of high false positives.  I want something that is 100% 
deterministic and believe SSP does that in the non gray DKIM-BASE areas. 

It is conceivable we can have a switch that says:

      [X] Promote Bad Signatures to No Signatures (default)

If this turns out be a high false positive area, then something has go 
to give.  We might add additional sub-options:

      [X] Promote Bad Signatures to No Signatures (default)
          [X] For ALL and STRICT policies only.

And this might help in minimizing the issue because as we all know, a 
major problem with DKIM is its optional and relax provisions and in this 
case, we might treat it just like any other message.  That might suggest 
that in a broken signature situation where a domain might have an 
optional signing policy (DKIM=UNKNOWN), "filters" might not want to 
ignore the fact that it was a broken signature so it can be used to 
learn from.

I don't have a problem with true no-signatures and I don't have a 
problem with "virtual" no-signature as well when the domain policy is 
restrictive.

Also remember the domain has the HANDLING= option so, overall, it might 
not be an issue for restrictive setups.

-- 
Sincerely

Hector Santos, CTO

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Dec 2007 10:44:32 -0800

Damon wrote:
> validity and drop the messages with no signature on the floor. 

That would be a bad idea. I believe they changed this in the most current
version, but gnu mailman -- as an example -- was stripping out DKIM
signatures thinking they were doing the originating domain a favor since
they "knew" that the signature would fail (which, in fact, wasn't always
the case). It took quite a bit of convincing on my part that they should 
just
leave it alone. It's not hard to understand their perspective though: they
thought a broken signature would look more spammy than a missing
signature. Rinse, repeat.

       Mike

---

From: Damon <[email-masked]>
Date: Thu, 20 Dec 2007 16:02:57 -0500

> signature. Rinse, repeat.

Just leave it to the developers to find a way around the problem
rather than just fixing it ;-)

I am sure that we could add some "best practices" and say that if you
are maintainig a STRICT or ALL policy then this ~may~ break mailing
lists. There are plenty of products out on the market that have
nothing to do with messaging that have these same sort of issues.
"Smoking Causes Cancer", "Don't operate heavy machinery", etc. I
believe that if big enough ISP's and businesses follow the rules, the
"broken" mailers will have to fix their issues rather then the policy
makers having to find ways around their issues. Allowances are going
to have to be made and a line in the sand drawn at some point... I
just hope that it is not 6 yards offshore.
If a domain can't live with loosing a mailing list, then my suggestion
would be either fix the mailing list or don't use ALL or STRICT. Seems
simple enough to me.

Regards,
Damon Sauer

---

From: Damon <[email-masked]>
Date: Thu, 20 Dec 2007 16:06:52 -0500

Can someone message Doug and tell him to stop blocking Gmail *sigh*.
The day Google become spammers is the day I will likely have to just
power down my systems and go home.

---------- Forwarded message ----------
From: Mail Delivery Subsystem <[email-masked]>
Date: Dec 20, 2007 12:29 PM
Subject: Delivery Status Notification (Failure)
To: [email-masked]

This is an automatically generated Delivery Status Notification

Delivery to the following recipient failed permanently:

    [email-masked]

Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 13): 554 Service unavailable; Client
host [209.85.146.178] blocked using qil.mail-abuse.com
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Dec 2007 14:43:42 -0800

On Dec 20, 2007, at 10:30 AM, Hector Santos wrote:

> If the SMTP client is going to strip signatures, then the verifier  
> is now in the 100% non-repudiated state of NO signature and will  
> label the message SUSPICIOUS for DKIM=ALL/STRICT policies.

They might remove _invalid_ DKIM signatures.

Without a valid signature, there is no "non-repudiated state".  A  
message without a valid signature from a domain claiming to have  
signed "all" messages means the state of a message is "non-compliant"  
with this assertion.  The domain is still free to either claim or deny  
having sent the message.  Don't use "non-repudiated" when this means  
"non-compliant".

> Well, of course, this is not an original source because if a SMTP  
> client is seeing bad signatures, you are assuming it itself did not  
> honor DKIM-BASE or SSP when it first received the message and  
> decided to redistribute or relay the mail.

Are you saying a message containing a From email-address from a  
foreign domain MUST NOT be sent when then using a header other than  
 From to indicate its origination?

The transmitting domain may still be sending a legitimate message.

> So all you really highlighting here is the need for the middle ware  
> to be protocol consistent as well.

Isn't the challenge for DKIM/SSP to be protocol consistent?

> policy, and it strips the signatures, then the final verifier will  
> have no problem marking this transaction as SUSPICIOUS per SSP-01.

A better term would be "non-complaint" with SSP, but from a "trusted"  
source.

> On the other hand, if Mailman left it alone, the verifier will be  
> left in a limbo state which can only be rectified with a HARD  
> requirement that STRICT means STRICT and broken also means the  
> message is SUSPICIOUS.  DKIM-BASE will justif[y] this hard SSP  
> requirement because of its broken to no-signature promotion mandate.

Spoofing invalid signatures is not difficult.  In either cases, an  
invalid signature is non-compliant with a policy of "all" or "strict"  
per SSP, not DKIM base.

>> If, or when, DKIM signature hygiene does becomes a common practice,  
>> as perhaps it should, then any invalid DKIM signature would be  
>> fairly indicative of either older systems already listed as being  
>> DKIM unfriendly, or newer and perhaps questionable systems behaving  
>> badly.
>
> So who is at fault here?
>
> 1) The user who didn't follow company policy and use a company  
> property outside its business interest?

A user may also decide to redirect a message "as-is" to their lawyer  
using Resent-From header, but this happens to break the signature  
nevertheless.

There are circumstances where a signature might be damaged and then  
not comply with "all" or "strict" without being due to misbehaviour.

> 2) Mailman or any other similar middle-ware who may not be DKIM and/ 
> or DKIM/SSP compliant and allowed the user to submit unauthorized  
> messages?

Yes, but again this is not an absolute sign of misbehaviour.  Messages  
from other sources must be evaluated separately.

> 3) Mailman or any other similar middleware who will strip and/or  
> strip/replace a redistribution because it has altered the mail  
> integrity?

This is no different from that of #2.

>> Weighing an invalid DKIM signature as 'implying' a message is  
>> likely to have originated from some domain invites bad behaviour  
>> that wastes valuable resources.
>

Only that you want resources wasted on invalid DKIM signatures?

>> Although an invalid signature should be considered equal to no  
>> signature (as also specified in the base specification), from the  
>> responses on this list, expect many will bet on initial statistics  
>> and get this wrong.
>
> I find this funny because I do seem to recall that you and others  
> were against restrictive policies because it was believe will  
> restrict and promote false positives in valid roaming users  
> situations.

Unnecessary disruption of legitimate communications was a concern.   
Protecting transactional messages should not unnecessarily disrupt  
communication because a message was sent by an office administrator on  
behalf of their manager, for example.

TPA-SSP was to permit a safe and reasonable means to "authorize" other  
domains.  DKIM should not become entangled with unwarranted  
expectations of providing authentication of identities associated with  
email-addresses.  "Per-user" keys raised this concern and necessitates  
handling exceptions.

DKIM should be about which domain originated the message.  SSP should  
be about which domains have been "authorized".  This authorization  
should not be limited to a single domain.  Ad hoc domain delegations  
or key exchanges are not safe and do not scale.  Necessitating  
bilateral arrangements hurts small domains, and who might then feel  
compelled to make such arrangements anyway.  A resulting aggregation  
of private keys will imperil overall security.

> The problem as I see it that these same people did not want to give  
> SSP the light of day in lieu of using A/R heuristics to address the  
> issue of valid vs broken signatures.

Invalid is no better than none from a security perspective.  Although  
SSP gets ugly, who said it would be pretty?

>> This does not bode well, and could represent a sizeable loss of  
>> receiver resources.
>
> But you need to see SSP is not the problem here.  It is DKIM-BASE  
> with its broken signature semantics.   SSP is fine when following  
> the DKIM-BASE broken signature to No Signature status. But you do  
> introduce FALSE POSITIVES into SSP because of it.   As the SSP  
> boundary table showed, the GREY area is when the signature is DKIM- 
> BASE signature is truly broken.

SSP _requires_ a _valid_ signature for compliance.  There is _no_ grey  
area with respect to compliance or whether a signature is valid.

> These can be a GOOD or BAD intention message.

Without a valid signature, there is no way to tell either way.  Any  
added acceptance based upon broken signatures invites abuse, and more  
broken signatures.  There are not enough resources to handle the  
resulting onslaught of broken signatures.

> Talking for myself here,  I don't want to implement something that  
> will have a history of high false positives.  I want something that  
> is 100% deterministic and believe SSP does that in the non gray DKIM- 
> BASE areas.
>
> If this turns out be a high false positive area, then something has  
> go to give.  We might add additional sub-options:
>

You mean demote bad signatures.  The lack of a valid signature  
confronts compliance requirements ONLY when the policy is "all" or  
"strict".  How many users would be confused by your view of "partial"  
broken signature compliance.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Dec 2007 14:57:50 -0800

On Dec 20, 2007, at 10:44 AM, Michael Thomas wrote:

> That would be a bad idea. I believe they changed this in the most  
> current version, but gnu mailman -- as an example -- was stripping  
> out DKIM signatures thinking they were doing the originating domain  
> a favor since they "knew" that the signature would fail (which, in  
> fact, wasn't always the case). It took quite a bit of convincing on  
> my part that they should just leave it alone. It's not hard to  
> understand their perspective though: they thought a broken signature  
> would look more spammy than a missing signature. Rinse, repeat.

A mailing-list not breaking signatures is a scary idea.  This would  
open the door for all sorts of abuse.

When a mailing-list signs using DKIM, while not modifying the From  
header, they should also expect verifiers to evaluate the From header  
signature first.  Depending upon the available resources, a second  
evaluation of the mail-list signature may not occur.  The _only_ way a  
mailing-list could ensure their signature is evaluated is to remove  
broken From signatures.  Leaving these broken signatures needlessly  
wastes resources and looks spammy.  From what you just suggested about  
not breaking signatures, their user's very messages might well be used  
to carry spam.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Dec 2007 15:07:53 -0800

Douglas Otis wrote:
>> out DKIM signatures thinking they were doing the originating domain a 
>> favor since they "knew" that the signature would fail (which, in 

Yesterday, of the 32082 messages that Cisco sent through mailing lists,
99.6% of them passed verification. Keep your grubby mitts off of the
supposedly broken signatures like RFC4871 says.

       Mike

---

From: Damon <[email-masked]>
Date: Thu, 20 Dec 2007 18:18:04 -0500

> supposedly broken signatures like RFC4871 says.

Exactly,

 So why again are we demoting broken signatures to No Signature? This
promotes ALL to STRICT.

Regards,
Damon Sauer

---

From: Hector Santos <[email-masked]>
Date: Thu, 20 Dec 2007 20:30:41 -0500

> Only that you want resources wasted on invalid DKIM signatures?

Who said that? I would appreciate you stop making up stuff and blurting 
it out as if that is what I said.

> domains.  

We are not talking about TPA here.

> You mean demote bad signatures.  

No. I said promote. BAD to NONE is a promotion. Not a demotion.

Please stop twisting what I said.

Under the default SSP policy (UNKNOWN or OPTIONAL signing), a bad 
signature promotion to NONE will validate the message as it never 
occurred.  The same will occur when a domain has a ALL|STRICT policy but 
the verifier does not support SSP.  Of course, opinion may vary, to me, 
I stand by the idea that is not a demotion of state, but rather a 
promotion.

-- 
Sincerely

Hector Santos, CTO

---

From: Damon <[email-masked]>
Date: Thu, 20 Dec 2007 21:15:41 -0500

Hector,

 You know me as a logical person that can persuaded into understanding
something that I might have disagreed with in the past and we usually
think alike. In this case, I am really trying to figure out how
promotion from BAD to NONE doesn't break ALL and promotes to STRICT.
Because a good or bad a signature is a signature whereas promoting a
BAD signature to NONE fails ALL and therefor promotes ALL to STRICT.
I realize in the real world we would likely promote BAD to NONE
~after~ the validation, but if we are going to do that way, then I
would like to see wording as such in the draft. With this in place, I
would not have an issue with it.

Regards,
Damon Sauer

---

From: Damon <[email-masked]>
Date: Thu, 20 Dec 2007 21:23:26 -0500

> would not have an issue with it.

After re-reading what I wrote, I (like most people likely) went "Huh?"
What I would like to see is something that keeps the integrity of ALL
without promoting to NONE and some implementer pointing to the RFC
later and saying "See, I handled this message correctly because I
promoted the broken signature to NONE" in the case where a broken
signature met an ALL policy.
Maybe it is just too late at night. My wordsmith went home.

Regards,
Damon Sauer

---

From: <[email-masked]>
Date: Fri, 21 Dec 2007 09:46:37 -0500

Gmail sends out a ton of spam, half of my phish return sites wrap to
gmail. Depending on Doug's settings and filters there is probably
something else going on.

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: Damon [mailto:[email-masked]] 
Sent: Thursday, December 20, 2007 4:07 PM
To: Douglas Otis
Cc: Oxley, Bill (CCI-Atlanta); [email-masked]
Subject: Re: [ietf-dkim] Accidental versus malicous error (was: SSP
assist DKIM)

---------- Forwarded message ----------
From: Mail Delivery Subsystem <[email-masked]>
Date: Dec 20, 2007 12:29 PM
Subject: Delivery Status Notification (Failure)
To: [email-masked]

    [email-masked]

---

From: <[email-masked]>
Date: Fri, 21 Dec 2007 09:53:21 -0500

Don't hit replay all :-(

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, December 21, 2007 9:47 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [ietf-dkim] Ping Doug

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: Damon [mailto:[email-masked]] 
Sent: Thursday, December 20, 2007 4:07 PM
To: Douglas Otis
Cc: Oxley, Bill (CCI-Atlanta); [email-masked]
Subject: Re: [ietf-dkim] Accidental versus malicous error (was: SSP
assist DKIM)

---------- Forwarded message ----------
From: Mail Delivery Subsystem <[email-masked]>
Date: Dec 20, 2007 12:29 PM
Subject: Delivery Status Notification (Failure)
To: [email-masked]

    [email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Fri, 21 Dec 2007 06:57:18 -0800

Stephen Farrell wrote:
> Hi Mike,
> Michael Thomas wrote:
>> 99.6% of them passed verification. 
>>     
>
> That's an interesting number, higher than I'd have thought. I'd
> have guessed ~50%.
>
> - any idea why its so high (are you doing anything odd in the
>   signatures?)
>   

l= with some z= magic. the point being that we understand the risks, and
we don't want net.busybodies telling us what is best for us. If any of this
becomes a real life problem -- which it is not -- there are plenty of other
mitigations we can take.
> - what causes contribute to the 0.4%
>   

there are definitely mailing lists out there that do things that we can't
recover from -- yahoogroups as an example. More interestingly though,
there are mailing lists managers that actually mangle the DKIM-signature
itself under some circumstances -- would that we kept nowsp for the
headers. Then the rest fall into a grab bag of different reasons.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Fri, 21 Dec 2007 11:46:53 -0800

> gmail. Depending on Doug's settings and filters there is probably  

I don't think this list should handle this topic, but I am not on  
MAAWG's.

Thresholds setting for these services are variable on a per customer  
basis.  Settings range from zero-tolerance to non-linear levels of ham/ 
spam ratios.  Several entities impact on this type of problem.  For an  
impact, there must be _some_ means to limit compromised system.  Our  
lists ensure message filtering is not clogged with spam, where  
aggressiveness is adjusted by the customer.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 21 Dec 2007 15:10:12 -0800

On Dec 21, 2007, at 6:57 AM, Michael Thomas wrote:

> Stephen Farrell wrote:
>> Hi Mike,
>>
>> Michael Thomas wrote:
>>
>>> Yesterday, of the 32082 messages that Cisco sent through mailing  
>>> lists, 99.6% of them passed verification.
>>
> l= with some z= magic. the point being that we understand the risks,  
> and we don't want net.busybodies telling us what is best for us.  If  
> any of this becomes a real life problem -- which it is not -- there  
> are plenty of other mitigations we can take.

What are the mitigations?

> there are definitely mailing lists out there that do things that we  
> can't recover from -- yahoogroups as an example. More interestingly  
> though, there are mailing lists managers that actually mangle the  
> DKIM-signature itself under some circumstances -- would that we kept  
> nowsp for the headers. Then the rest fall into a grab bag of  
> different reasons.

Mailing lists removing _invalid_ signatures will not impact results  
obtained with mailing-list permissive settings.  Removing invalid  
signatures better ensures evaluation of valid signatures.

In addition, it is a matter of interpretation as to whether a mailing- 
list should remove signatures prior signing.  It is not that far  
fetched to predict dependence upon permissive signature settings and  
mailing lists not removing prior signatures is likely a recipe for  
future policy compliance problems and represents valid concerns when  
deciding upon policy assertions.

When exploits occur when using mailing-list permissive settings and  
restrictive policies--

-  what will be asked of the signer?

-  what will be asked of the verifier?

-  what will be asked of changes to the policy?

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Fri, 21 Dec 2007 15:56:35 -0800

> What are the mitigations?

They're secret. And obvious.

> In addition, it is a matter of interpretation as to whether a 
> mailing-list should remove signatures prior signing.  It is not that 
> far fetched to predict dependence upon permissive signature settings 
> and mailing lists not removing prior signatures is likely a recipe for 
What part of RFC4871 section 4.1 paragraph 3:

  Signers SHOULD NOT remove any DKIM-Signature header fields from
  messages they are signing, even if they know that the signatures
  cannot be verified.

is not clear? Your fanciful leaps of what-if's fly in the face of my field
tested 99.6% pass rate, not to mention that you are simply wrong about
what rfc4871 says.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Fri, 21 Dec 2007 19:13:17 -0800

> They're secret. And obvious.

Is there a reason this list should not be able to review a strategy  
that significantly limits signature coverage in order to comply with a  
policy assertion?

>> mailing-list should remove signatures prior signing.  It is not  
>> that far fetched to predict dependence upon permissive signature  
>> settings and mailing lists not removing prior signatures is likely  
>> a recipe for future policy compliance problems and represents valid  
>> concerns when deciding upon policy assertions.
>
> is not clear? Your fanciful leaps of what-if's fly in the face of my  
> field tested 99.6% pass rate, not to mention that you are simply  
> wrong about what rfc4871 says.

This was section 4.2. "Interpretation" of section 4. "Semantics of  
Multiple Signatures".

Following this sentence is:
,---
Verifiers MAY process signatures in any order of their choice; for  
example, some verifiers might choose to process signatures  
corresponding to the _From_ field in the message header before other  
signatures.  See Section 6.1 for more information about signature  
choices.

Verifiers SHOULD ignore failed signatures as though they were not  
present in the message.  Verifiers SHOULD continue to check signatures  
until a signature successfully verifies to the satisfaction of the  
verifier.  To limit potential denial-of-service attacks, verifiers MAY  
limit the total number of signatures they will attempt to verify.
'---

Section 6.1 tends to repeat the same advice:
,---
When a signature successfully verifies, a verifier will either stop  
processing or attempt to verify any other signatures, at the  
discretion of the implementation.  A verifier MAY limit the number of  
signatures it tries to avoid denial-of-service attacks.
'---

If or when spam begins to abuse DKIM signatures, an evaluation limit  
of one may not be unusual, or the exclusion of evaluations from  
sources emitting a high level of invalid signatures.  Fully benefiting  
from DKIM may require removal of signatures known to be invalid.   
Evaluating DKIM signatures requires more of heavily taxed resources.   
The "even if they know that the signatures cannot be verified" may  
prove to be bad advice.  Changing this advice to "unless they know  
that the signatures cannot be verified" does _not_ affect your 99.6%  
results.  The "even if they know that the signatures cannot be  
verified" necessitates expending additional resources per message  
checked.  Is this really wise when spam is the majority of message  
traffic?

-Doug

---

From: Hector Santos <[email-masked]>
Date: Fri, 21 Dec 2007 22:43:49 -0500

> signatures better ensures evaluation of valid signatures.

That depends Doug.

As a Mailing list server author, there are some major redesign 
considerations here especially where SSP is concern.

There is no way we would not consider all or part of the following for 
our List Server DKIM/SSP logic.

If the list admin wishes to do any one of the many long time
common MLS features that essentially alters the originality of
the new list message, and it wishes to provide protocol consistency for 
the DKIM domain, then it must consider the following:

1) As part of the list subscription verification process, the
    MLS will verify that the subscribing domain is not restricted
    via SSP by perform a simple lookup.

1a) If the policy is STRICT, the subscription will be denied IFF
     the list is not prepared to alter the integrity of the message.
     It will behave as a simple passthru redistribution mailer.

1b) If the policy is ALL, then this allows the MLS to:

     - leave the message alone if its not going to alter the
       integrity of the message, or

     - strip the original signature IFF it is prepared to
       resign.  Although DKIM-BASE has semantics to say only
       one signature is required to be valid,  this option
       may help minimize downlink issues.

1c) If the policy is UNKNOWN (optional), then this is where
     the complexity might begin since the MLS can create
     false positives.  We might not even worry about DKIM
     domains without SSP or those with direct DKIM=UNKNOWN
     policy. Ignore them completely and let the download
     handle it.  But I can also see the logic to maybe:

     - Leave the SIGNED message alone (valid/invalid) if its
       not going to alter the integrity of the message, or

     - Strip the VALID original signature IFF it is going to
       alter the message and not resign.

Overall, I think:

If the MLS sees the arrival of a new submission with a invalid 
signature, I don't think the MLS should attempt to "promote" it to a 
state where it could be viewed as an optional signing.  If you strip it, 
then you might do more harm than good here.

If the new list message arrives with a valid signature, then what 
happens next depends on whether the MLS is altering the message, and/or 
the DOMAIN has a SSP policy that is restrictive.

if the new list message arrives with no signature, then depending on the 
SSP, the MLS logic can be easily defined.

The whole point is that ideally, the MLS can be made to be protocol 
consistent with DKIM/SSP.

Now is that feasible? It is asking too much of list servers?

Those (MLS people) who need it will do what it takes to make it work. 
Others might not.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Fri, 21 Dec 2007 23:29:18 -0500

> They're secret. And obvious.

Surreal.

> is not clear? 

Michael,

I see a recommendation (SHOULD NOT) there, not a requirement (MUST NOT).

Although in principle I agree with you, from a MLS designer standpoint 
there are engineering considerations where a strip and/or strip/replace 
may apply.  It depends on the input and what is expected for the output 
to keep with protocol consistency.  It depends on SSP.

Your 99.6% is impressive but also dubious since you haven't spelled out 
the various system parameters, processors, list configurations involved, 
such as:

  - What MLS software are we talking about? one or any one?

  - Are they DKIM or DKIM/SSP ready?

  - Are they resigning?

  - Where is this 99.6% verification place?  At the downlinks?

  - What munging options are enabled for the various list?

  - If mail is being munged, in particular adding subject list name
    tags, how do you get around new postings, rinse repeat,
    new postings, not responses, getting munged thus initiating the
    alteration and invalid signature?

Responses are fine for validation. The subject tag has been altered and 
stable now within reply messages and by using a length, you can exclude 
footers thus achieve a high validation. I can see that.

But I don't see how you have wide control over any original submission 
alteration destroying your original signature.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Sat, 22 Dec 2007 20:58:42 -0800

On Dec 21, 2007, at 7:43 PM, Hector Santos wrote:

> If the list admin wishes to do any one of the many long time common  
> MLS features that essentially alters the originality of the new list  
> message, and it wishes to provide protocol consistency for the DKIM  
> domain, then it must consider the following:
>

Expecting mailing-lists to accommodate DKIM policies is another way of  
saying these services will be disrupted, as mailing-lists won't in  
many cases.

>    It will behave as a simple passthru redistribution mailer.

That does not represent the operation or criteria used with the  
typical mailing list.

Mike has suggested that by limiting the extent of DKIM signature  
coverage, failure rates can be lowered to about 1 in 250, and this  
appears to suggest specific message formats must be used.

With Mikes approach-

  a) users receiving a DKIM verified messages are assured less  
protection, and will be at greater risk of being deceived

  b) when exploited, message filtering must then be used on the  
unsigned portions of the message

  c) higher level of legitimate messages will be in conflict with DKIM  
policy assertions

>      may help minimize downlink issues.

There might be some concerns regarding errors induced when handling  
multiple signatures.  Perhaps when the list is moderated, timeliness  
may suffer.  As much as possible, efforts needed to ensure signed  
messages comply with a DKIM policy should be established by the domain  
used in the From header.

1) Do not ask for additional receiver side processing of invalid  
signatures.

2) Do not lower benefits obtained from processing DKIM signatures by  
imposing partial coverage.

Give verifiers a good reason to process DKIM signatures!

>      alter the message and not resign.

A mailing list that applies SSP policy on incoming messages prior to  
posting, removes full-coverage signatures prior to flatting and other  
alterations, and then adds their full-coverage signature, safely  
permits other domains to "authorize" its output.   The means to  
authorize mailing-list signatures can be accomplished with a single  
TPA-SSP record with a scope of Sender, and not depend upon key  
exchanges or domain delegations.  While this will upset Mike, removing  
original signatures eliminates a bad practice of extremely limited  
signature coverage needed to survive list handling.  It would also  
encourage the use of TPA-SSP authorizations by those attempting to  
impose either "all" or "strict" policies.

> state where it could be viewed as an optional signing.  If you strip  
> it, then you might do more harm than good here.

I am unsure what you mean by "promote".

When a mailing list applies DKIM policy to incoming messages,  
including initially invalid signatures is likely to be misleading, and  
a "proper" signature offers _no_ subsequent value when it is likely to  
be damaged by list handling.  A safe solution would be to remove  
initial signatures.  Uncertainty as to whether the removed signature  
was ever valid should not matter.  Only the signature added by the  
list offers tangible benefit.  Invalid signatures represent a waste of  
resources and invite partial coverage signatures, which is a bad  
practice from a security standpoint.

> happens next depends on whether the MLS is altering the message, and/ 
> or the DOMAIN has a SSP policy that is restrictive.

There might be a few such lists around.  Should these be called  
exploders? : )

> if the new list message arrives with no signature, then depending on  
> the SSP, the MLS logic can be easily defined.
>
> Those (MLS people) who need it will do what it takes to make it  
> work. Others might not.

The burden should be placed on domains imposing restricted policies.   
TPA-SSP is how this problem is best managed.  The mailing-list  
operators should be able to keep doing what they are doing, check for  
policy compliance on incoming messages, and add their DKIM signature  
to their output.  Use of the From header can be accommodated when it  
is authorized and signed by specific Sender headers for example.

-Doug