----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
There are clearly some proposed features where standardising would
probably be premature. However, I suspect there are also some core
features of SSP where we will achieve rough consensus for
standardising now. I at least won't be surprised if we end up
with SSP only specifying a very small set of practices but also
being extensible. (We'll need to discuss extensibility requirements
at some point btw.)
Hi Stephen,
FWIW, my opinion....
I don't undersstand why we can't just have a mechanism that exposes the
physical possibilities for signatures and let the domains define what is
possible for them?
This is what the basis idea with the two axis concept that quite a few
people agreed with since last year with their own or similar ideas as
follows:
1P=NEVER | ALWAYS | OPTION // 1st party
3P=NEVER | ALWAYS | OPTION // 3rt party
The only thing that was missing and agreed by all, was a need for a "allow
list" of some kind:
3PL=options list of 3rd party domains
With these three items, it covers all possible physical signature
fingerprints and combinations. It addresss most, if not all, possible
practical scenarios.
Of course, its quite possible most domains will only zero in on the most
useful policies that makes sense for them, but having this way will limit
domains to the limited behaviors based on the philosophies of just a few
people.
Consider the possibility that if we limit the policies, this might just have
the opposite effect when bad actors specifically create and target scenarios
that that are not covered by the limited SSP standard.
With that said....
In my review of SSP-02, it should all to over all scenarios except for the
3rd party Allow list. SSP-02 leaves this open-ended and I feel that is a
mistake. It needs to be defined.
Here is a table I produced showing how it covers all possible policies
(except the 3rd party list)
EXPECTATION SSP-02 DKIM-BASE RESULT
----------- ---------- --------- ------
OPTIONAL p=UNKNOWN NO SIGNATURE CONSISTENT
OP PASS CONSISTENT
OP FAIL SUSPICIOUS/IGNORE
OP FAIL-NOKEY SUSPICIOUS
3P PASS ACCEPT
3P FAIL SUSPICIOUS/IGNORE
3P FAIL-NOKEY SUSPICIOUS
NO MAIL p=STRICT NO SIGNATURE SUSPICIOUS
OP PASS INCONSISTENT*
OP FAIL SUSPICIOUS
OP FAIL-NOKEY SUSPICIOUS
3P PASS SUSPICIOUS
3P FAIL SUSPICIOUS
3P FAIL-NOKEY SUSPICIOUS
NEVER SIGN p=STRICT NO SIGNATURE SUSPICIOUS
OP PASS INCONSISTENT*
OP FAIL SUSPICIOUS
OP FAIL-NOKEY SUSPICIOUS
3P PASS SUSPICIOUS
3P FAIL SUSPICIOUS
3P FAIL-NOKEY SUSPICIOUS
SIGNED p=STRICT NO SIGNATURE SUSPICIOUS
OP PASS CONSISTENT
OP FAIL SUSPICIOUS/IGNORE
OP FAIL-NOKEY SUSPICIOUS
3P PASS SUSPICIOUS
3P FAIL SUSPICIOUS
3P FAIL-NOKEY SUSPICIOUS
SIGNED p=ALL NO SIGNATURE SUSPICIOUS
OP PASS CONSISTENT
OP FAIL SUSPICIOUS/IGNORE
OP FAIL-NOKEY SUSPICIOUS
3P PASS UNKNOWN
3P FAIL UNKNOWN
3P FAIL-NOKEY SUSPICIOUS
* Should not happen
As you can see, some of the expected policies can be folded under the
p=strict policy, in particular NO MAIL and NEVER SIGN can be folded by
creating a NULL public key. The only issue here is that you need TWO DNS
lookups to accomplish this. One to get the p=strict policy and one to find a
null public key.
In short, I think Jim did a great job with SSP-02, but it needs to now focus
on the 3rd party list which Jim calls "Verifier Acceptable 3rd party" in
section 2.10:
2.10. Verifier Acceptable Third-Party Signature
A Verifier Acceptable Third-Party Signature is a Third-Party
Signature that the Verifier is willing to accept as meaningful for
the message under consideration. The Verifier may use any criteria
it deems appropriate for making this determination.
You can't leave this open-ended. There is needs to be a definition defined
to the domain responsible for all this. I think once this is done, we are
basically there.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html