On August 16, 2005 at 15:43, "Hector Santos" wrote:
Verify Results:
NONE - No signature in mail
PASS - Good Signature, Original Address Signer
PASS 3PS - Good Signature, 3rd party Signer
FAIL - Bad Signature, Original Address Signer
FAIL 3PS - Bad Signature, 3rd party Signer
and in particular these last two. Specifically, if the treatment
for FAIL or FAIL 3PS is more favorable than NONE, attackers will
simply put broken signatures into their mail and to get the more
favorable treatment. Trying to divine the difference between a
broken signature and a faked signature, well, requires the
divine :)
Therefore, when a signature fails, the immediate decision
should assume worst-case scenario to avoid attackers exploiting
weak policies on signature failures.
[Unquoted table to keep it from wrapping]
Table 1.0 - DKIM Verification States illustrates all possible
outcomes for signature verification against SSP.
+------------------------------------------------------+
| Sender Signing Policy Result |
+-----------+----------------------------------------------+-------|
| result | WEAK | NEUTRAL | STRONG | EXCLU | NEVER | NONE |
| verify | OPT | OPT/3PS | REQ/3PS | REQ | | |
+-----------+--------+---------+---------+--------+--------+-------|
| NONE | accept | accept | reject | reject | reject | accept|
|-----------+--------+---------+---------+--------+--------+-------|
| PASS | accept | accept | accept | accept | reject | warn |
|-----------+--------+---------+---------+--------+--------+-------|
| PASS 3PS | reject | warn | accept | reject | reject | warn |
|-----------+--------+---------+---------+--------+--------+-------|
| FAIL | warn | warn | warn | warn | reject | warn |
|-----------+--------+---------+---------+--------+--------+-------|
| FAIL 3PS | reject | warn | warn | reject | reject | warn |
+------------------------------------------------------------------+
I think that the rows of NONE, FAIL, and FAIL 3PS all ought to
be the same. Right?
Trying to show all the possibilities, and even then, there are sub-levels -
a 3rd dimension. :-)
For the verify=NONE row (no signature present), I think the outcomes (or
assertions) are different than when a signature does exist. No signature,
this means an automatic reject for STRONG, EXCLUSIVE and NEVER signing
policies. When a failed signature is present, for STRONG and EXCLUSIVE
policies, you don't know why it failed. Hashing? Expired Key? So I put a
warning here.
It should be reject. I think the FAIL rows should be reject across the
board. Policies should not allow wiggle room for failed signatures,
otherwise attackers will exploit them (some leniency may be doable,
see below).
The possible reasons you state that warn may be warrented, actually
are reasons for rejection. For example, if a key expires, that
indicates the key is no longer valid and should not be in use.
Those with strong signing policies should expect strong verification
policies.
But what if there is no PUBLIC KEY? Then I think it would
REJECTS instead of WARNING, because it doesn't make sense to have a SSP
Record but not a KEY record.
Agreed.
Or could this be a DNS lookup failure issue?
If DNS lookup is failing, the message should be requeued for later
processing, or if verification is done during an SMTP session,
a temporary reject can be indicating so sender can resend later.
Consider the NONE column:
Is a NONE policy really the same as a NEUTRAL policy?
No.
Per SSP
specification, a domain with no SSP DNS record, defaults to a NEUTRAL
policy.
I do not like this since attackers can exploit domains that have
not adopted DKIM. If no record is present, a signature on a
message should be considered suspicious. Rejection should be
acceptable behavior in this case, and at a minimun a warning.
Another nit is that we probably need to be a little bit more mealy
mouthed about what accept/reject/warn mean. In particular, I don't
think that a receiver policy of "reject" (assumedly a 5xx) would
be feasible any time soon. Take for example this mailing list which
mangles my message even though I have set a policy of o=-; Would
you really reject it? I'd be very hesitant to recommend anything
that drastic.
Right. Don't you think the WARNing is appropiate for this STRONG/FAIL
state?
I agree. There are a bunch of reasons why things will fail. That is why I
think we need to able to hash them out and see what can be done.
And any leniency leaves room for attackers to exploit. Warning may
be acceptable, but how the warning is presented to the recipient of
the message is crucial.
Some signature failure conditions should always indicate rejection:
Key expiration, key revocation, non-existent public key, malformed
signature data. This is why knowing why a signature failed is
important. If everything looks good, but the hashes do not match,
then outright rejection may not be completely desirable.
In this case, the SSP could determine what the verifier should do
since the behavior should be consistent. I.e. If SSP will not
support failure policies, then all verifiers should treat a fail
condition the same (to avoid exploitation).
If SSP allows failure policy definitions, some domains may be willing
to live with hash not equal failure if a warning is provided (since
the domain does not want to prevent complete rejection of email).
While others may want a stricter policy.
The forwarding/mailing-list scenario does complicate things. Hence,
some domains may support a warning for hash failure during early
deployment, but will hope forwarding/mailing-list services will change
so rejection can be done.
If we were able to detect a HASHING failure, for example, the "virtual"
warning/logging (asssesment) might be:
"WARNING: This message failed a DKIM hashing error."
Of course, a message like to a receipient will just confuse them.
Something more useful will need to be communicated to a recipient.
On a related note, if you knew that a mailing list is going to break your
DKIM signature, is this a reason for not signing it in the first place? and
if so, how is done? What if you knew the mailing list was going to resign
the mail? That would satisfy your STRONG policy, but it totally breaks
non-3rd party signing domain policies.
This is where a failure policy support can be useful. Domains can
initially state that hash failure (remember, some failures should
always indicate reject) provides a clear warning. Over time, mailing
list software and forwarders will modify they way they operate to
avoid breaking DKIM signatures.
For example, the List-* header fields explicitly exist to provide
list meta-information, so why add auto-footers (I know, MUAs need to
support displaying List-* headers, but they can do that when adding
DKIM verification support :).
DKIM may be a problem for mail list services that like to auto-add
ads to messages.
If we are going with the SPECS that we have today, then it is my opinion,
you have to have this consistency check at a minimum.
All verification behavior must be consistent in how successes and
failures are handled. If variability in behavior is determined to
be essential (especially during early DKIM adoption) such behavior
should be controled by SSP. If verifiers are allowed discretion on
how to treat things, it opens up things to exploitation.
--ewh
_______________________________________________
ietf-dkim mailing list
http://dkim.org