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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html