[ietf-dkim] Accidental versus malicous error

[Douglas Otis]

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

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

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

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

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?

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

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.
>
> No dispute there. I always said that.

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

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

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