Section 5 is pretty clear about security threat potentials about removed
all considerations in SSP-02 to deal with them.
| 5. Security Considerations
|
| Security considerations in the Sender Signing Practices are mostly
| related to attempts on the part of malicious senders to represent
| themselves as other authors, often in an attempt to defraud either
| the recipient or an Alleged Author.
|
| Additional security considerations regarding Sender Signing
| Practices may be found in the DKIM threat analysis [RFC4686].
|
| *<<<THIS SECTION IS NOT COMPLETE.>>>*
I suggest the following be added in part or in whole to the section:
There are clear and present danger with high potential frauds which
SHOULD NOT be ignored if we are to gain any payoff or add-valued
secured benefit for signers, verifiers and users:
The fraud are exhibit when transactions contradict the following
domain expectations:
o NO MAIL EXPECTED
o OPTIONAL 1ST PARTY SIGNING ONLY
o STRICT 1ST PARTY SIGNING ONLY
o 1ST OR 3rd PARTY SIGNING REQUIRED
These represent the key propositions in the protocol consistency of
the DKIM model and they can offer immediate and high potential
security protection against current legacy domain forge abuses and
expected DKIM-adapting mail abuses.
Please keep in mind that these are not signature or domain reputation
evaluators but fundamental DKIM protocol consistency checks. It may
be viewed a "DKIM Policy Declaration" Checking. In addition, there
is no verifier mandated handling requirement. All handling language
recommendations cited below are defined by RFC2119.
o NO MAIL EXPECTED
One of the largest abuse of domains are forged mail transactions
which are using RFC2822 From: domains which are not valid Email
hosting domains and/or were not expected to be used for email
transaction by the principal owner of the domain.
Protection is offered in SSP-02 as follows:
Domains can implicitly state mail is not expected by creating a NULL
public key to force invalidation of a signature. Augmenting this
with a DKIM=DISCARDABLE enforces the requirement of a valid
signature, therefore with the lack of valid signature, the message
SHOULD be rejected without prejudice.
o OPTIONAL 1ST PARTY SIGNING ONLY
Conventional wisdom suggest that domain explorers of DKIM
will test the waters using an optional 1st party signing
policy. Some messages will be signed while others are not,
but they don't expect 3rd party signers to "test" the waters
for domain.
Unexpected 3rd party signing protection is not offered via SSP-02.
A new explicit policy DKIM=OPTIONAL is recommended that
distinguishes itself from the current DKIM=UNKNOWN which allows
anyone to sign and misrepresent the domain.
DKIM=OPTIONAL (NEW)
This policy declares the domain signing practices are optional, but
only expect its own domain to sign the mail. No other 3rd party
representation is expected. A message containing a 3rd party
signature SHOULD be rejected without prejudice.
o STRICT 1ST PARTY SIGNING ONLY
This protection is offered using DKIM=DISCARDABLE. A message with no
signature or containing a 3rd party signature SHOULD be rejected
without prejudice.
o 1ST OR 3rd PARTY SIGNING REQUIRED
A weak protection is offered using DKIM=ALL. It is weak because it
allows for an inconsistent state to exist without prejudice and
lacks handling semantics for the detectable inconsistent DKIM=ALL
policy transaction. A message with no signature or containing a 3rd
party signature MAY be rejected without prejudice.
--
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