Subject: [ietf-dkim] SSP additional tag?

From: Damon <[email-masked]>
Date: Wed, 2 Aug 2006 11:47:43 -0400

I know that I am writing this a great risk of being flamed but the more I
think about it the better it sounds to me.
I believe that it will help with the "I sign some mail" and "I sign no mail"
issues.

What about using an additional tag to specify where I always sign mail from.

Such as "I always sign mail from servers on my SPF record or CIDR(s)"

_domainkey DNS TXT record adding the additional tag (w):

example._domainkey.example.com. IN TXT "g=; w=spf or (<cidr>[,<cidr>,...]);
k=rsa; p=<key>"

This way, domains can junk "I sign some mail" can specify that "I always
sign based on my (w) tag"

Flame away!

Regards,
Damon Sauer
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: wayne <[email-masked]>
Date: Wed, 02 Aug 2006 11:10:27 -0500

> Such as "I always sign mail from servers on my SPF record or CIDR(s)"

For me, one of the big advantages of DKIM/DK is that it doesn't break
(as often) on forwarding, which complements SPF which doesn't break
(as often) on mailing lists.

Maybe I'm missing something, but I'm not sure that specifying the
source MTA that signs stuff has any real advantage over just using
SPF.

-wayne

---

From: Damon <[email-masked]>
Date: Wed, 2 Aug 2006 14:16:19 -0400

If I have a domain that my ISP is my MTA then my ISP is my SPF.
In this case, if the message is signed, it is truly specific to me.

And I disagree with the breaking of forwarding...

User A sends a message from the home office in Walla Walla. It is signed by
the home office's MTA and also by the ISP's MTA and is delivered to User B's
MTA. B's MTA checks the DKIM record which shows that I aways sign messages
coming from MTA A's ISP's IP. (or you can take A's ISP out of the mix)-
Works great.

User A then travels to Pasadena and forwards a signed message from the
Holiday Inn. Since the signature is in the header, it is assumed that it is
signed and B's MTA will still check the signature and it will still be good.
Regardless of whether Holiday Inn's MTA also signed the message.

User A then sends a new message from Holiday Inn to user B whose MTA checks
the DNS record which shows that only messages from user A's IP range *must*
be signed. Since it does not all within this range. The message will still
be good.

Regards,
Damon

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 2 Aug 2006 11:32:23 -0700 (PDT)

Some people unfortunetly never introduced tag (present for example in IIM)
specifying which server actually adds DKIM signature. This makes it 
impossible to extend in the way you proposed as receiver would not know
server/network responsible for adding particular signature when email
is actually being proposed.  As far as what you proposed about SPF I
would advise against it due to different identities being involed at
DKIM and SPF and mixing it up is a security hole that may only become
apparent long time in the future.

---

From: Damon <[email-masked]>
Date: Wed, 2 Aug 2006 15:26:03 -0400

On 8/2/06, william(at)elan.net <[email-masked]> wrote:
> > It does not matter which server adds the tag, only which server is the
> > sending MTA.
>
> DKIM is protocol that does not have much to do with SMTP session.
> As I said - to add this feature in you need to have DKIM signature
> that will tell you which server added it (which is not that hard at
> all and brings number of additional features).

Are you saying the the receiving MTA is not going to know what IP it
received the message from?
or are you saying that there may be multiple receiving MTA's that will each,
in-turn, check the signatures? Here I see it breaking. Could you include
this information in the DKIM header information then?

> Mixing DKIM and SPF was where I expected to get flamed- In which case, it
> is
> > just as easy to set the CIDR's in the DKIM dns entry. While it is
> SPF-like
> > it doesn't mean this really good idea can't be reused.
>
> CIDR does not make sense with DKIM. Listing of domains or servers does
> make sense.

CIDR's would not require many more additional lookups.

> Come on William.. how many good arguments do I need to convince you ;)
> >
> > Regards,
> > Damon
> >
> >
> > On 8/2/06, william(at)elan.net <[email-masked]> wrote:
> >>
> >>
> >> > I know that I am writing this a great risk of being flamed but the
> more
> >> I
> >> > I believe that it will help with the "I sign some mail" and "I sign
> no
> >> mail"
> >> > issues.
> >> >
> >> > What about using an additional tag to specify where I always sign
> mail
> >> from.
> >> >
> --
> William Leibzon
> Elan Networks
> [email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 2 Aug 2006 12:34:05 -0700 (PDT)

> received the message from?

More precisely the system doing DKIM checking is not going to know it
or even more precisely we should not assume that it would have any
knowledge about it (at least not on the protocol level).

> in-turn, check the signatures?

That may happen, but it is not the core of the problem. The core is that
DKIM is message content based verification system and thus should not be
tied to SMTP session.

> Here I see it breaking. Could you include

Yes. Just add a tag which specifies FQDN name of the host that added the 
signature. I talked about it long time ago on mailsig mail list.

---

From: Damon <[email-masked]>
Date: Wed, 2 Aug 2006 15:41:40 -0400

William,

 I see adding this to the Signature as fixing a lot of issues.
Why was it dropped?
Can it be re-visited since at this point it is valuable again?

Regards,
Damon Sauer

On 8/2/06, william(at)elan.net <[email-masked]> wrote:
> >> >> Some people unfortunetly never introduced tag (present for example
> in
> >> IIM)