Frank Ellermann wrote:
Hector Santos wrote:
If we don't wish to consider this now, I can see an I-D proposing an
update to RFC 4871 to add the SSP=strict|all tag. Is that the better
approach?
I still don't see how adding the SSP info to DKIM records could help
receivers confronted with an unsigned mail. Why would the receiver
prefer to get the DKIM info when what he needs is the SSP info ? Or
do you propose to integrate SSP wholesale into DKIM, no separate SSP
at all ?
The sub-steps provided in the original messages explained the logic.
In SSP-01, Step 1 has:
1. If a valid Originator Signature exists, the message is not
Suspicious, and the algorithm terminates.
This means that the signature was verified via DKIM-BASE. It also means
the DKIM key record was obtained and all information points to a 1st
party signature.
If we continue beyond step 1, this implies we have the following states:
a) valid 3rd party signature, or
b) no signature (which can be from a broken signature).
So step 2 and 3 deals with the SSP discovery process in order to address
these two states.
The proposal is this:
We can reduce (not eliminate) step 2 and 3 by short circuiting the steps
if the DKIM key record obtained in step 1 contained the SSP policy
information; SSP=strict|all
So in step 1, we can add the following sub-steps:
1a) If we have a valid 3rd party signature or no signature resulting
from a failed DKIM-signature validation, and the key record
contains a tag SSP=strict, then the message is Suspicious and
the algorithm terminates.
1b) If we have no signature resulting from a failed
DKIM-signature validation, and the key record contains
a tag SSP=ALL, then the message is Suspicious and the
algorithm terminates.
The whole point is that under strict DKIM/SSP operations there is only
one party involved and no other party or unsigned messages are expected
and under the ALL policy, there is only 1 state the message can be in -
a signed state.
In both cases, we short circuit the need to do a SSP discovery by adding
an optional DKIM-BASE SSP= tag option to DKIM-BASE key records.
If the message is not signed and/or the failed DKIM signature key record
contains no SSP= tag, then the verifier would proceed with the current
recommended steps 2 as stated in SSP-01.
A point to consider is that the proposal deals a Negative Classification
only, hence bad guys will not have any incentive to exploit.
If the strategy goal of DKIM-BASE is to get "everyone" to consider DKIM
signatures, then this includes the high value domains who will want to
use this technology in exclusive, highly restrictive operations. This
is where the highest benefits and payoff is obtained in utilizing this
technology.
Therefore, having a SSP=restrict|all in the DKIM key record is
undoubtedly a massive improvement in the overall model, reducing DNS
concerns, simplifying the SSP protocol while still offering the same
ideas DKIM+SSP attempts to offer without introducing any new threats.
--
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