----- Original Message -----
From: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>
I think Jim mentioned this too, but I really like this table
was well. I do have some nits about it though...
Just providing my insight. No claim to all being 100% worked out. Overall,
I'm just trying to get the people to consider these terms to analyze the
entry points for possible threats and to make the corrections in the
automation possibilities.
What I stated I think is a good start. No doubt, there should be
corrections.
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 :)
[I made the typo corrections to the legend]
I agree. This is possible threat in the DKIM state table. That is why I
have "warn" results, which basically mean "Throw up hands." What do you do?
Is the problem related to not knowing the hash failed vs. the signing? Was
it due to an expiration?
[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. 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. Or could this be a DNS lookup failure issue?
Consider the NONE column:
Is a NONE policy really the same as a NEUTRAL policy? Per SSP
specification, a domain with no SSP DNS record, defaults to a NEUTRAL
policy. So you would think that NONE/PASS should be the same as a
NEUTRAL/PASS, thus making both columns the same.
This could be true for verify = PASS, but not verify=FAIL or FAIL 3PS
because you are not sure why it failed.
For example, if it failed due to not having a PUBLIC KEY, than a NONE might
really be a REJECT. But in the NEUTRAL column, this implies there exist a
SSP DNS record. So it might not be a automatic REJECT.
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.
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."
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.
Nonetheless, this is all part of analyzing the threats, entry points,
assets, trusted entities, etc.
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. In all honesty, I
think this is all that is needed at this stage. Just needs fine tuning.
After we get the consistency phase worked out, then comes the optional
"confirmation phase" where we might want to callout to some
vouching/reputation system. But there is no need for confirmation if the
consistency is not there.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org