Michael Thomas wrote:
It appears that we can discard this concern as counterfactual. I
asked how people sort their list mail, and here's what I found:
Somebody needs to tell John that what "people" (= end users) do with
their mail, list or otherwise, is not the entire universe of possibilities
of using DKIM. How people sort their mail isn't a useful gauge of utility.
+1.
Trying to make some sense of this, I presume John's main point is that
the 8522.From has lesser value from a sorting and trusted list
distribution standpoint and that most (if not all) of the trust would
be based on a (presumed) dominant filtering and recognized trusted
list-id header.
In other words when a list message contains a signature signed by the
list domain and the domain matches the 5822.List-ID domain, such as
the mail from this list:
DKIM-Signature: d=mipassoc.org;
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
Then a trusted list-id domain recognized by the user makes the
security issues related to trust using the 2822.From is less significant.
Well, never mind the idea that MLS software makes it an option to add
List-XXXX headers, although an DKIM updated MLS would probably need to
enforce it for DKIM support, we still have the 5+ year plus issues of
1st vs 3rd party signature faults.
All we would be doing here is shifting the 2822.From domain DKIM
signature correlation to a different header id and we would have a
presumption it will always be 1st party LIST DOMAIN signature.
If there was one major consensus from all sides, documented in the
Thread Analysis and translated into the SSP functional requirements is
that everyone agreed the 1st party self-asserting valid DKIM
signatures need no policy lookup confirmation. A valid 1st party
signature is only possible when the 1st party domain prepared it to be
publicly validated. The only security thread was internal compromising
of the the domain.
The problem and WG conflicts has always been how to deal and control
of unsolicited, unexpected, anonymous and abusive 3rd party signatures.
So I see no difference here using a LIST-ID domain as the "binding
correlation" with DKIM signature. What if its a 3rd party LIST signature?
DKIM-Signature: d=mipassoc-BAD-GUY.org;
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
If the user sorts by LIST-ID, he will still have the possible valid
signatures from unknown 3rd party domains and the only way to resolve
this takes us back to square one - 1st versus 3rd party expectations
using a DKIM augmented technology concept where the list-id domain
exposes the "expectations" for signatures - either from a policy
record or from some reputation databases.
Either way, Using 5322.From or 5322.List-ID domain bindings, the 1st
vs 3rd party signing expectation issues are still there.
--
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