----- Original Message -----
From: "Paul Hoffman" <phoffman(_at_)proper(_dot_)com>
True. However, even if they are optional, they have to be fully
specified in order for people in the WG to understand if they are
relevant or necessary. The parts that I miss in this thread is: "for
this particular optional statement of policy, what is the recipient
of that policy message expected to do? What are the requested to do?"
This is long discussed in both SSP-01 and DSAP-00:
http://tools.ietf.org/html/draft-allman-dkim-ssp
http://tools.ietf.org/wg/dkim/draft-santos-dkim-dsap-00.txt
In addition, the following table created long discussions since last year to
serve as a basis for discussion. Nearly everyone felt it helps in
structurely what needs to be discussed and was.
Table 1.0 - DKIM Verification States illustrates all possible
outcomes for signature verifcation against SSP.
+----------------------------------------------+
| Sender Signing Policy Result |
+-----------+----------------------------------------------|
| result | WEAK | NEUTRAL | STRONG | EXCLU | NEVER |
| verify | OPT | OPT/3PS | REQ/3PS | REQ | |
+-----------+--------+---------+---------+--------+--------|
| NONE | accept | accept | reject | reject | reject |
|-----------+--------+---------+---------+--------+--------|
| PASS | accept | accept | accept | accept | reject |
|-----------+--------+---------+---------+--------+--------|
| PASS 3PS | reject | accept | accept | reject | reject |
|-----------+--------+---------+---------+--------+--------|
| FAIL | warn | warn | warn | warn | reject |
|-----------+--------+---------+---------+--------+--------|
| FAIL 3PS | reject | warn | warn | reject | reject |
+----------------------------------------------------------+
In addition, the current open SendMail source code (dkim-milter-0.5.1) has
current support only for:
Signature Optional (o=~ DKIM_POLICY_SIGNSOME)
Signature Expected (o=- DKIM_POLICY_REQUIRED)
Signature Not Expected (o=. DKIM_POLICY_NEVER)
The 3rd party restrictive policy DKIM_POLICY_AUTHORITY (o=!) as defined in
SSP-01 is not SUPPORTED. There is no action for it.
This can only be assumed to be based on the idea that 3rd party or middle
ware signing is not be restricted.
One question that keeps coming back to me is if all this push back is to
avoid more code changes that is already in the DKIM public API vaults?
Some of that is because the tone of the messages is "this is obvious"
(which it is not),
We can agree they are not obvious to everyone, but what is? Rest assured,
the most obvious will be first thing exploited whether we recognize it now
or not.
DSAP address obvious exploits that will occur in a DKIM-BASE only
environment that follows fundamental security and protocol consistency
considerations.
The first obvious problem starts during initial deployment with the
reception of non-signed messages which may have an domain expectation to be
signed. Is that not obvious?
Other obvious exploits:
- No mail is expected to be distributed,
- Mail is signed (good or bad) and its not suppose to be, and
- you didn't expect other people to be signing for you.
Now those are obvious exploitations because unless you do anything to
control it or make a protocol declaration that they are not threats, they
will cause inconsistencies that will make DKIM less valuable.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html