Subject: re: [ietf-dkim] Seriously.

From: [email-masked]
Date: Thu, 24 Jan 2008 08:19:23 -0500

>> 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

---

From: Damon <[email-masked]>
Date: Thu, 24 Jan 2008 11:30:19 -0500

> domain B can reorder this prior to signing:

+1

>   | See Note1 below on this.                            |

I am not so sure about this, please see my reasoning below

> DKIM d= domain is not matching the x822.From domain part.

I believe that 3rd party signing and this issue are separate.

> regardless of the From: list order.

Only if d=B and there has been a reorder. Without the reorder, the
responsible party (at least in the readers eyes) is A.

> use Sender: only if it matches and it helps define the order of the

I believe that we should say that in the absence of a d= the first
from address will be the default author.

> What rule is necessary for multiple SSP policies?

None. Regardless of the policies of the other From: addresses, if a d=
exists and there has been a reorder, the author is, at this point,
defaulted to the first address. Anything else and we are going to
break VERP implementations.

>      was not signed, then it would be viewed as suspicious.

Agree

>      Domain A is unprotected. This message should be suspicious.

Disagree-
There should be a reorder in this case where after processing:

From: B,A,C
DKIM-signature: d=B
A is no longer the author.

>      D=A matches one of the STRICT domains, this this may be an

This is ok. The author is correctly identified and checked.

>      If we allow this, then we have a loophole.

Disagree-
If we allow reordering, it would then be allowed.

Regards,
Damon Sauer