Subject: [ietf-dkim] NEW ISSUE: Security Threat: Unexpected Third Party Senders

From: Hector Santos <[email-masked]>
Date: Mon, 11 Feb 2008 20:07:20 -0500

| A.4.  Third Party Senders
|
|   Another common use case is for a third party to enter into an
|   agreement whereby that third party will send bulk or other mail on
|   behalf of a designated author domain, using that domain in the
|   RFC2822 From:  or other headers.  Due to the many and varied
|   complexities of such agreements, third party signing is not
|   addressed in this specification.  The authors anticipate that
|   as mail systems gain experience with DKIM, it will become
|   possible to codify best practices of this and other usages
|   of DKIM.

The fallacy in the "common use case" opinion stated above is that it has 
limited insight and is based on the idea that a most domains may wish to 
be part of a 3rd party Bulk mailer system or will part of a prior 3rd 
party agreement or have a inherent TOS with 3rd party signers.

Besides the obvious security fact this introduces a security threat of
email forgery and mis-representation, the reality is such that a
majority of the domains on the internet will not intend to participate
in such 3rd party agreements nor do not wish to have any represented by
3rd party signers in any shape or form, regardless of good or bad
intentions of the 3rd party.

The exclusion of 3rd party restrictions makes it possible for ANY domain
to be abused by 3rd party mis-representation.

Proposed change:

  A.4.  Third Party Senders

    Another common use case is for a third party to enter into an
    agreement whereby that third party will send bulk or other mail on
    behalf of a designated author domain, using that domain in the
    RFC2822 From:  or other headers.

    However, this common use case has the potential to open a security
    hole with 3rd party DKIM signers misrepresentation of domains.

    To secure against this potential security threat, if the RFC2822
    From: domain contains any the following SSP policies, the receiver
    SHOULD honor these policy semantics:

    DKIM=DISCARDABLE
    DKIM=OPTIONAL

        DKIM=DISCARDABLE is a 1st party only signing requirement and
        DKIM=OPTIONAL is a 1st party only signing option.

        No 3rd party signer is expected for these policies,
        therefore, a message containing  a 3rd party signature will
        be a contradiction of the explicit domain signing practice.
        With these policies, the Author
        Domain is informing the receiver the message SHOULD be
        not be acceptable for user delivery and they do not intend
        to take any responsibility for any harm caused by accepting
        this unexpected representation of their domain. It MAY be
        rejected without prejudice.

    In lieu of the above explicit SSP policies, due to the unknown models
    available for valid 3rd party arrangements, these unknowns models
    SHOULD be passed to future 3rd party signing Evaluators.

-- 
Sincerely

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

---

From: "J D Falk" <[email-masked]>
Date: Tue, 12 Feb 2008 17:26:27 -0500

> party agreement or have a inherent TOS with 3rd party signers.

That's not quite what we had in mind.  As I see it, 3rd party signing is
only acceptable when the domain owner wants to permit it -- so if
there's no agreement, the entire discussion of 3rd party signing is
irrelevant.  This is more or less your argument, too, so we probably
just need to tighten the wording of that paragraph so that it's clear
that it means what we both want it to mean.

I'm not cool with replacing an "out of scope" statement at the tail end
of an appendix with normative demands of specific verifier behavior,
however.

---

From: "Siegel, Ellen" <[email-masked]>
Date: Tue, 12 Feb 2008 17:40:05 -0500

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of J D Falk
> 
> Hector wrote:
> 
> > limited insight and is based on the idea that a most domains may
wish
> to

3rd party signing is acceptable as long as the domain owner doesn't
explicitly forbid it by publishing a policy to that effect. Some domain
owners may be willing to leave the decision to their individual account
owners rather than enforce a domain wide policy one way or the other.

3rd party signing is one of the important flexibilities of DKIM: any
party (or parties) can take responsibility for a message. It seems a
shame to just toss that out because it's potentially exploitable. 

> of an appendix with normative demands of specific verifier behavior,

+1

Ellen

---

From: "J D Falk" <[email-masked]>
Date: Tue, 12 Feb 2008 17:51:14 -0500

Ellen gently disagreed with me, as I thought she might:

>> irrelevant.
 [ . . . ]
> owners rather than enforce a domain wide policy one way or the other.

This is why we need to leave it out of scope, and debate more later.
*grin*

--
J.D. Falk
Receiver Products
Return Path

---

From: John Levine <[email-masked]>
Date: 13 Feb 2008 04:51:16 -0000

>That's not quite what we had in mind.  As I see it, 3rd party signing
>is only acceptable when the domain owner wants to permit it --

Huh?  The various mail forwarders I use at ieee.org and my college
alumni association will eventually sign stuff on the way through.  In
some cases, they may even add a Sender header or something else that
breaks the original signature.  But I'm going to accept it no matter
how the original sender fulminates.

It would be possible to design a system in which domain A says that it
endorses domain B's signature on mail with an author address at A, but
if you dig through the list archives, you'll find that we rejected
that expansion of SSP quite a while ago.

Trying to forbid random other third party signatures is, as I expect
you'd agree, just silly.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 Feb 2008 02:20:44 -0500

>> Hector wrote:
 >>
 >> The fallacy in the "common use case" opinion stated above is
 >> that it has limited insight and is based on the idea that
 >> most domains may wish to be part of a 3rd party Bulk mailer
 >> system or will part of a prior 3rd party agreement or have a
 >> inherent TOS with 3rd party signers.

J D Falk wrote:

 > That's not quite what we had in mind.  As I see it, 3rd party
 > signing is only acceptable when the domain owner wants to permit
 > it -- so if there's no agreement, the entire discussion of 3rd
 > party signing is irrelevant.

This sounds like an OPT-OUT signing model.

So why do you advocate an inherent "policy and mandate" against allowing 
a domain owners (and the key words is owners) the option and flexibility 
to opt out with a global declaration -

       "I don't expect 3rd party signatures in my direct 1 to 1
        private email communications with my target recipients."

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 Feb 2008 02:44:05 -0500

> Trying to forbid random other third party signatures is, as I expect

John,

This falsely assumes the long held *User Expectations* governed and 
protected by the 1986 US EPCA is no longer valid for direct private 1 to 
1 email communications.

It advocates the idea that some random unknown router(s) outside the 
administrative domains on both ends has the god given right not only to 
destroy mail integrity, is allowed to mis-represent a domain without 
prejudice but also in a new DKIM era, to be able to assert a 3rd party 
digital signature on behalf of the message owner and domain where it has 
no business in doing in the first place.

What is odd, even if it was a silly idea, is why the uncompromising 
stubbornness in not allowing not even the OPTION for the domain to 
define its own destiny in not expecting mail tampering and false 
representation in some random router between end points.

You are not even allowing the industry to live and learn if protection 
against this obvious security thread is helpful or not. I  believe it 
will be proven to be helpful.  It certainly isn't going to hurt anyone. 
The worst case is certain domains might quickly find out the "policy" 
doesn't work for them and they simply turn it off.

Stop being so darn stubborn.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 Feb 2008 05:03:47 -0500

> that expansion of SSP quite a while ago.

hmmmmm, I don't believe that is true John.  I think you are reading your 
own adaptation where stripping down SSP-01, removing such Verifier 
Accepable 3rd party Signature semantics from the spec, relabeling it ASP 
does not make it "while ago".  I think I am fairly certain ASP is only 
week or so old.

Anyway, while there were various proposals and ideas not everyone was 
tickled pink with, it was quite clear the concept was feasible enough to 
get written in stone in SSP-01:

2.11.  Verifier Acceptable Third-Party Signature

    A Verifier Acceptable Third-Party Signature is a Third-Party
    Signature that the Verifier is willing to accept as meaningful for
    the message under consideration.  The Verifier may use any criteria
    it deems appropriate for making this determination.

3.  Operation Overview

    ..

    2.  All messages from this domain are signed.  Messages containing a
        Verifier Acceptable Third-Party Signature MUST NOT be considered
        Suspicious.

           NON-NORMATIVE RATIONALE:  Third-party signatures, since they
           can potentially represent any domain, are considered more
           likely to be abused by attackers seeking to spoof a specific
           address.  It may therefore be desirable for verifiers to apply
           other criteria outside the scope of this specification in
           deciding to accept a given third-party signature.  For
           example, a list of known mailing list domains used by
           addresses served by the verifier might be specifically
           considered acceptable third-party signers.

And in RFC 5016, it goes as far as using suggesting DNS CNAME techniques:

    6.  Because DKIM uses DNS to store selectors, there is always the
        ability for a domain holder to delegate all or parts of the
        _domainkey subdomain to an affiliated party of the domain
        holder's choosing.  That is, the domain holder may set an NS
        record for _domainkey.example.com to delegate to an email
        provider who manages the entire namespace.  There is also the
        ability for the domain holder to partition its namespace into
        subdomains to further constrain third parties.  For example, a
        domain holder could delegate only _domainkey.benefits.example.com
        to a third party to constrain the third party to only be able to
        produce valid signatures in the benefits.example.com subdomain.
        Last, a domain holder can even use CNAME's to delegate individual
        leaf nodes.  Given the above considerations, SSP need not invent
        a different means of allowing affiliated parties to sign on a
        domain's behalf at this time.

-- 
Sincerely

Hector Santos, CTO

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Feb 2008 06:05:24 -0800

> that expansion of SSP quite a while ago.

   Indeed, it was issue tracked, consensus called and documented in
   RFC5016. This is a very dead horse.

		Mike

---

From: "J D Falk" <[email-masked]>
Date: Wed, 13 Feb 2008 21:09:25 -0500

Hector ranted:

> So why do you advocate an inherent "policy and mandate"
> against allowing a domain owners (and the key words is
> owners) the option and flexibility to opt out with a global
> declaration -
> 

We get that exact statement from the "discardable" flag.

What ASP (and SSP-02) /don't/ permit is for a domain owner to say "I'm
cool with 3rd party signatures," either by prior agreement or random
happenstance.  That's what I want to leave out of scope, and deal with
in the future.

---

From: "J D Falk" <[email-masked]>
Date: Wed, 13 Feb 2008 21:14:24 -0500

> Trying to forbid random other third party signatures is, as I expect

And yet, treating any random third party signature as if it's just as
valid as a first party signature is, as I expect you'd agree, the kind
of security issue that would cause someone to stand up on a chair and
shout "DKIM will never be useful for anything, and you people all suck
toads!"

Yet another reason to leave 3rd party signatures (and toad-sucking) out
of scope, I suppose.

---

From: John Levine <[email-masked]>
Date: 14 Feb 2008 04:40:17 -0000

>shout "DKIM will never be useful for anything, and you people all suck

I suppose, although it mostly makes me wonder if there's any way to
explain DKIM to the bufophagists.

A third party signature from a stranger is useless, I don't ever
recall anyone claiming otherwise, and I've never understood why this
red herring comes up over and over and over and over and over again.
But a first party signature from a stranger is equally useless, unless
one finds assertions along the lines of "I, Mr. X, really sent this
spam!" to be helpful.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Thu, 14 Feb 2008 00:33:12 -0500

> red herring comes up over and over and over and over and over again.

Let me take a guess.

Could it be because you have selective bias to ignore and neglect all 
security concerns expressed over and over again by legitimizing the 
existence of unexpected states that is fundamentally conflictive with 
existing long held private email practices?

In layman terms, while stating a 3PS is useless without some form of 
non-repudiated prior arrangement is plausible, the mere fact for the 
unexpected existence of 3PS has a tremendous value in the area of mail 
tampering and fraud detection and protection.

IMO, to ignore this is irresponsible.

Just consider that by believing a 3rd party signature is useless, this 
premise alone may be enough to provide justification for a verifier to 
"discard" any message with a 3rd party signature.

Why?

Because your model implies there should never exist a 3rd party 
signature due to its useless value, therefore no legitimate DKIM signer 
would ever attempt to sign as a 3rd party.

Unless your ASP model has specific semantics to not DISCARD 3rd party 
signatures, as did SSP-01, be careful for what you ask for because this 
might be exactly what will happen inevitable. After all, you said 3rd 
party signatures are useless.

-- 
Sincerely

Hector Santos, CTO

---

From: "Siegel, Ellen" <[email-masked]>
Date: Thu, 14 Feb 2008 10:33:41 -0500

> Yet another reason to leave 3rd party signatures (and toad-sucking)
out

Explicitly out of scope. Because not all 3rd party signatures on email
are "random", and there are a number of valid use cases that include
them. 

Ellen

---

From: [email-masked] (Wietse Venema)
Date: Thu, 14 Feb 2008 11:03:11 -0500 (EST)

> are "random", and there are a number of valid use cases that include

+1. This horse is dead and stays dead.

	Wietse

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Feb 2008 08:19:41 -0800

> +1. This horse is dead and stays dead.

I like a quote that I think I once heard attributed to Usenet:

"a stain in the middle of the road where once laid a dead horse"

		Mike

---

From: Hector Santos <[email-masked]>
Date: Thu, 14 Feb 2008 13:01:49 -0500

> are "random", and there are a number of valid use cases that include

hmmmmm, this sounds like an explicit in scope statement.

So essentially, if I read you correctly,  you want MTAs to completely 
ignore messages with 3rd party signatures as if the message was never 
signed?

At what point or stage during the transport and/or delivery process do 
they become "in play" and for whom?

According to Falk, if I read him right, he indicated a domain can use 
DKIM=DISCARDABLE to protect against unwanted 3rd party signatures.

Do you agree?

-- 
Sincerely

Hector Santos, CTO