Ned Wrote:
This is an interesting, even novel approach. I'm still
trying to evaluate it. One question I have is how it would
interact with what headers are covered by the author
signature. In particular, does the Sender: field in this
case have to be covered by the signature?
Jim Wrote:
It might need to be, but I have a bigger concern about
alternative 2. The Sender address and From address(es) have
different meanings. Just because a particular author happens to
be the sender of the message, should that affect which domains'
signing policies apply? I can't see why it should, which is why
I favor alternative 1 given that we're not going to do something
arbitrary in the multiple-From case.
+1.
Jim, I sure you are aware of the following, but I would like to
highlight some key points:
o Sender Usefulness for SSP/DKIM:
The only usefulness I see for Sender: is possibly as a "optimizer" to
possibly preempt multiple co-author domain lookups. But I can only see that
as "safely" true if the Sender: header is bind (bound) by the digital
signature.
o Protocol Consistency:
The DKIM/SSP security/protection offered for a normal, more common, single
From: author transaction MUST NOT be trumped by a multiple From: list
transaction.
The protocol consistency must be consistent for the entire x822.From domain
list. At best, we can recommend that the signer use the "primary" domain
it is signing for, as the first address in the list. This might require
reordering of the list when the message is first submitted for signing.
Example of reordering (optional optimization)
From: A, C, B, D
A new message was created by a user B and he wishes to add co-authors A, C
and D to the From: header. For some odd-ball, but still technically legal
reason, the user B address is not the first:
Nonetheless, User B submits it to his/her MSA and the MSA signing for
domain B can reorder this prior to signing:
From: B, A, C, D
Dkim-Signature: d=B
+-[ NOTE ]+-------------------------------------------+
| |
| The MSA may also want to check the SSP for domains |
| A, C and D to make sure they are not DKIM=STRICT. |
| See Note1 below on this. |
| |
+-----------------------------------------------------+
As the logic is currently defined, a 3PS (3rd Party Signature) is when the
DKIM d= domain is not matching the x822.From domain part.
So in this case, the signature d=B helps by checking the primary domain B
regardless of the From: list order.
The Sender:, if provided, can possible add "weigh" if it was also pointing
to domain B.
Sender: B
From: A, C, B, D
Dkim-Signature: d=B
and under this "all" matching case, there would be no need to reorder the
From: list.
o Missing Signature
Of course, the situation is when we don't have a signature and we want to
find what policies apply to the unsigned message.
I don't think we can trust relying on Sender: especially if the domain is
not among the From: list. So at best, an verifier can possible choose to
use Sender: only if it matches and it helps define the order of the
preferred lookup.
In all cases, we can not violate the basic principle in SSP From: domain
requirement - the single From: domain logic must be consistent with a
multiple From: domains logic.
Note #1:
What rule is necessary for multiple SSP policies?
This question pertains to how mixed SSP policies are interpreted.
In order to be protocol consistent, IMO, any domain exposing a DKIM=STRICT
or DKIM=ALL policy can not be violated by other mixed restrictive policies.
I think we need to look at the mixed possibilities in order to get a handle
on this multiple From: domains SSP logic. Here are few examples:
Example 1:
From: A, B, C
DKIM-signature: d=A
A --> DKIM=STRICT
B --> NO SSP (DKIM=UNKNOWN)
C --> NO SSP (DKIM=UNKNOWN)
Issues:
I see no Issue. Perfect SSP/DKIM protection. If the message
was not signed, then it would be viewed as suspicious.
Example 2:
From: A, B, C
DKIM-signature: d=B
A --> DKIM=STRICT
B --> NO SSP (DKIM=UNKNOWN)
C --> NO SSP (DKIM=UNKNOWN)
Issues:
Domain A is unprotected. This message should be suspicious.
Example 3:
From: A, B, C
DKIM-signature: d=A
A --> DKIM=STRICT
B --> DKIM=ALL
C --> DKIM=STRICT
Issues:
Can't have two DKIM=STRICT?
One consideration might be, maybe as long as a valid
signature was found any of the STRICT domains, in this case
D=A matches one of the STRICT domains, this this may be an
exemption.
However, this would be a LOOPHOLE if we allow this.
Example 4:
From: A, B, C
DKIM-signature: d=B
A --> DKIM=STRICT
B --> DKIM=ALL
C --> DKIM=STRICT
Issues:
Even though domain B allows anyone to sign, can it sign
on its own behalf and still use strict co-domains?
If we allow this, then we have a loophole.
Overall, I think if any domain shows a DKIM=STRICT policy, then it can not
be violated, otherwise we defeat the purpose of this powerful mechanism to
protect high-value domains who DO NOT intend to be "promiscuous" with there
usage of their domain on the internet and which to use their property
exclusively for
their own mail operations.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html