should accept dkim based on from address and signing address belonging to the same person

You want to limit DKIM to cases where the signing domain (d=) matches the From domain in the body of the message. Looking at Sender and ignoring From puts the identity precedence backwards. It is not unheard of for mailing lists to add a sender header and for mailing lists to add DKIM signatures. If there were a mailing list hosted under the domain in question, relying on Sender might allow malicious commands to be authenticated:

1. Sign up for mailing list on target domain.
2. Send message to mailing list (LP won't get this because it's not subscribed).
3. Collect message plus signature from mailing list.
4. Replay message with rcpt to LP.
5. Profit.

Keep in mind that envelope identities like rcpt to are not bound to DKIM signatures and so replay like this is trivial. It's not currently done because it's not valuable to do so. Please don't make it valuable to do so.

If I understand Scott's concerns correctly, this means that Martin's first set of bullet points (which includes "there is a Launchpad account P with active email addresses for both the Sender and From addresses" and "the dkim signature covers both the From and Sender fields") is OK, but the simplified version he proposed is not. Please correct or confirm.

Right. Including Sender would open up the concern that I've mentioned. If you look at the DomainKeys policy element you'll see it included Sender. For the DKIM policy element, ADSP, it does not include sender due to this exact concern.

I'm fine with only doing the first case, ie checking both From and
Sender are validated addresses for the same account.

On 20 September 2010 16:41, Scott Kitterman <email address hidden> wrote:
> You want to limit DKIM to cases where the signing domain (d=) matches
> the From domain in the body of the message.  Looking at Sender and
> ignoring From puts the identity precedence backwards.  It is not unheard
> of for mailing lists to add a sender header and for mailing lists to add
> DKIM signatures.  If there were a mailing list hosted under the domain
> in question, relying on Sender might allow malicious commands to be
> authenticated:
>
> 1. Sign up for mailing list on target domain.
> 2. Send message to mailing list (LP won't get this because it's not subscribed).
> 3. Collect message plus signature from mailing list.
> 4. Replay message with rcpt to LP.
> 5. Profit.
>
> Keep in mind that envelope identities like rcpt to are not bound to DKIM
> signatures and so replay like this is trivial.  It's not currently done
> because it's not valuable to do so.  Please don't make it valuable to do
> so.

I don't see the vulnerability in this example. I think this would
mean there was a message with Sender: <email address hidden> From:
<email address hidden>, with both fields signed by example.com.
This is only a problem if Impersonated has already, through the web
ui, added <email address hidden> as one of their email addresses?

--
Martin

I think we now agree on what would be done to close this bug, therefore moving it out of incomplete.

mp https://code.launchpad.net/~mbp/launchpad/643223-dkim-aliases/+merge/74061

Fixed in stable r13958 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13958>.

With help from Haw I tested this on qastaging:

 * mail From my gmail address: accepted
 * mail From my canonical address, via gmail, signed by gmail: accepted (the point of this bug)
 * unsigned mail attempting to create a new bug: rejected
 * gpg signed attempting to create a new bug: accepted
 * unsigned mail appending to an existing bug (weak auth ok): also accepted

so it looks all ok.

There is a follow-on <https://code.launchpad.net/~mbp/launchpad/mail-script/+merge/75488> but it only affects developer tools and doesn't need qa.