Subject: [ietf-dkim] Message Replay Abuse and Acceptance of a Signature

From: Douglas Otis <[email-masked]>
Date: Sat, 21 Jan 2006 12:45:45 -0800

Replay Abuse Damaging Signature Acceptance:

Company X sends out a newsletter offered by free subscriptions verified
with a double-opt-in process.  A similar situation to that of a list-
server or a free email-address provider.  Company X signs their
newsletter with the expectation that the signature improves the
acceptance of their messages.

Bad-Actor Y subscribes to newsletter of Company X using a free email-
address obtained from a large Domain Z.  Bad-Actor Y receives the
newsletter, and redistributes the newsletter through pirate systems with
the intent of damaging the acceptability of Company X signatures.  The
motivation may be extortion, disrupting competition, or a senseless act
of vandalism.

As it happens, Company X makes a separate signature for each recipient
and responds by excluding the email-address used by Bad-Actor Y when
they issue their next newsletter.  Domain Z is very large and there are
always new subscriptions from this domain.  This time a different email-
address from Domain Z has again redistributed the newsletter.  Company X
was warned initially, and now appears on a block-list where the
unintended distribution has made Company X appear to be a spammer.

A reputation service would be unable to respond with "bad" signatures in
a timely fashion to effectively squelch a rapid redistribution.  Company
K within the same industry decides Company X is playing unfairly and
that they too should send newsletters anywhere and blame complaints on a
message replay abuse problem, just as Company X has done.  Company X is
a good actor, and Company K is a bad actor, but both appear to be
signing messages sent to unsubscribed recipients.

This problem will exit within any free-email domain, a large domain
subjected to compromised systems, and list-servers, in addition to other
scenarios.  A conclusion soon likely reached by many recipients will be
that signatures, due to replay abuse effectively removing outbound
constraints, are worthless as a means for basing acceptance.  While some
may view DKIM offering value by removing non-conforming messages, even
this mechanism is easily circumvented.

A Low Administrative Solution Insensitive to High Latency:

Just as email domains check lists when deciding to receive a message,
they now also check a list to decide whether to sign, or perhaps even
send a message.

With this paradigm, as a best practice, to ensure Company X that it is
safe for them to send their newsletter, Domain Z replaces the incoming
signature with an MDA specific signature at the edge of their AdmD.  An
MDA specific signature can not be used to resend a message, but still
allows users of Domain Z to be assured the message is valid, and the
completed by Domain Z when the message first arrived.

Domains not replacing the incoming signature with an MDA signature are
at risk of either receiving messages unsigned or perhaps not receiving
messages at all once DKIM becomes more widely adopted.

Impact:

"Thin" mediators should not be used as this interferes with assessing
the behavior of the destination and may subject the "Thin" mediator to
being assessed as an abusive destination.

Closed Email-address policies become more problematic when the decision
not to sign may also cause the message to not be accepted.  Initially, a
DKIM-Adopters list may help remedy this problem.

-Doug 

_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 22 Jan 2006 10:25:31 +0100

> Just as email domains check lists when deciding to receive a
> message, they now also check a list to decide whether to
> sign, or perhaps even send a message.
 
> With this paradigm, as a best practice, to ensure Company X
> that it is safe for them to send their newsletter, Domain Z
> replaces the incoming signature with an MDA specific
> signature at the edge of their AdmD.  An MDA specific
> signature can not be used to resend a message, but still
> allows users of Domain Z to be assured the message is valid, 
> and the completed by Domain Z when the message first arrived.

Any sender X arranges something with most of its receiving Zs.
Any receiver Z arranges something with most of its inbound Xs.

Why do they need DKIM for that ?  CSV or SPF should be enough.

                          Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Sun, 22 Jan 2006 08:31:08 -0800

> Any receiver Z arranges something with most of its inbound Xs.

Perhaps for a great while, the choice would be whether is is safe to
sign the message or not, when hoping to retain the acceptance value of
the signature.  The replay abuse problem will effect both large and
small domains.  Checking a DKIM-Abuse-List (negative) or DKIM-Adopters-
List (positive) does not represent any 1:1 arrangements.  Commerce
related transactions may wish to use a negative list, and list-servers,
newsletters and the like, may be safer with a positive list.  Community
lists represent roughly the same level of care and cooperation exercised
in the process of receiving email for most domains.

> Why do they need DKIM for that ?  CSV or SPF should be enough.

For any crypto scheme, CSV could be useful to guard being overwhelmed
with bad actors by using a name-base reputation scheme.  Retaining
protection in the name space prevents collateral blocking and allows
double use for the DKIM-Abuse-List.  The minimums in SPF can make being
overwhelmed worse, even beyond the path registration issues.

The DKIM signature however indicates the AdmD providing initial access
and not just the last hop.  When there is an abuse problem, DKIM would
be effective at indicating the source of the problem.  DKIM would be
effective at indicating the source of the message for recognition and
recognition signaled security as well.  Signaling anything based upon
email-address conformance would be highly unsafe, severely limiting the
value of SSP.

Review the dkim-options draft.  The signature header is not removed,
just the 'b=base64' is obfuscated with a result indicating whether the
MDA verified the signature upon acceptance.  To prevent intra-AdmD
spoofing, the MDA does the obfuscation and resigns the message and
overlaid signatures.  A Public-Key is not necessary for the MDA
signature.  The MDA 'w=' parameter ensures this signature will not be
accepted by any other AdmD.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 22 Jan 2006 18:57:26 +0100

Douglas Otis wrote:

> The DKIM signature however indicates the AdmD providing
> initial access and not just the last hop.

Your X + Z example sounded like Z getting X's newsletters
directly (MON X to MRN Z).  For that case reducing it to
the one critical hop where one of X's MTAs determined one
of Z's MXs is an obvious solution, they should definitely
use SPF or CSV or similar if they want to know "does that
MTA claiming to be X really belong to X ?"

But if you have MRN Z behind any mediator(s) Z' we get the
known cases 1123 5.3.6(a) and (b).  Plus Hector's variant,
where mediator Z' replaces the signature of X by its own.

For the latter arrangements between X and Z cannot help,
Z has to trust Z' and maybe arrange something with Z'.
Dito:  X would have to arrange something with Z'.  That
case isn't interesting for DKIM, it's much more straight
forward to use SPF or CSV or similar for neighbours.

For _unmodified_ mails Z will "see" X's signature even if
it's behind Z'.  That sounds a bit like a "Web of trust"
reduced to AdMDs, the "society of wannabe-legit mailers":

Each MRN (Z) deciding which MONs (X) are IN or OUT from
its POV.  Okay, could work, no obvious problems so far.

                      Bye, Frank

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 22 Jan 2006 18:46:55 +0000

Douglas Otis wrote:
> The signature header is not removed,
> MDA verified the signature upon acceptance.  

I hate to do this yet again, but the term obfuscation is taken,
and not for what you mean, which confuses me at least. Quoting
[1] for example:

    obfuscation - technology to shroud the context and contents of code. 

    Obfuscated applications function properly, yet confuse human
    observers and decompilers.

> The MDA 'w=' parameter ensures this signature will not be

Ok, so you mean something like having an MDA sign in order to
attest that the message arrived with status <foo>. Our charter
has a stretch goal for that specifically not to be done without
a recharter:

    Once the primary goals are met, the DKIM working group may also study
    whether to adopt a work item for specifying a common mechanism to
    communicate the results of message verification to the message
    recipient. The generation of a standards-track specification on this
    topic will require an update to the DKIM working group charter.

So, I'd have to wonder how what you're proposing doesn't match
that paragraph, and is thus for later, and not for now.

Stephen.

[1] http://www.preemptive.com/documentation/glossary.html

---

From: Douglas Otis <[email-masked]>
Date: Sun, 22 Jan 2006 12:02:59 -0800

>     observers and decompilers.

Would the term signature-overlay or perhaps signature-masking be okay?

>     topic will require an update to the DKIM working group charter.

What is being proposed is _not_ a new header or a fundamental change to
the DKIM signature.  This proposal involves an introduction of a single
character 'w=' parameter added to the signature.  The 'w' parameter
defines which essential elements isolate the source of the message, as
well as the role of the signer.  In the case of the MDA signature, the
dkim-options draft defines the MDA (MDA AdmD) role represented as
'w=X'. 

The current base DKIM draft does not define how multiple signatures are
handled, how mediators are recognized, or how replay abuse can be
prevented.  The rather simple 'w=' parameter adds to the DKIM signature
a basis for solutions for resolving these open issues.  This simple
option should not demand a recharter in order to resolve some rather
basic issues, some of which were raised in the initial review conducted
by Russ.  This option is also upwardly compatible with the current
implementations.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Sun, 22 Jan 2006 12:52:19 -0800

On Sun, 2006-01-22 at 18:57 +0100, Frank Ellermann wrote:
> directly (MON X to MRN Z).

This example was illustrate the futility of handling a replay abuse
issue on an email-address bases.  The example could have used an email-
address from any domain.  The point to be made was that this issue can
be resolved on a domain basis when incoming signatures are overlaid with
a result and where an MDA signature can be added for protection within
the MDA AdmD.  The MDA could also simply strip overlaid signatures not
overlaid by the MDA.  This would provide roughly the same poor level of
security as would adding a results header. 

> For that case reducing it to the one critical hop where one of X's
> MTAs determined one of Z's MXs is an obvious solution, they should
> definitely use SPF or CSV or similar if they want to know "does that

Not exactly, this is about protecting the signature.  The use of DKIM-
Abuse-List mirrors a similar lists when receiving, where CSV could be
used to offer a name basis.  This proposal is about where to send the
signed message.  The value of DKIM is that it provides greater assurance
of the message source.  CSV provides the last hop which will will
require greater administrative effort to correlate common sources.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Jan 2006 01:21:42 +0000

Doug,

> Would the term signature-overlay or perhaps signature-masking be okay?

Were it me, I'd first consult the literature before inventing
any new terminology related to digital signatures. At the least,
I'd first ask someone who's familiar with that literature.

Without having checked, I can't say either of those terms ring
a bell, but using clear, unambiguous terms is a good thing and
[ab|re]using existing terms in odd ways is a bad thing.

> character 'w=' parameter added to the signature.  

Part of the problem with this proposal is the sales-talk that
accompanies it. You clearly know that it is not significant that
"w=" rather than "malarkey=" is just a few characters shorter and
you also know that that fact is totally unworthy of mention.

> prevented.  

IMO, none of the above necessitate assertions made on behalf of
MDAs (to use your term).

 > The rather simple 'w=' parameter adds to the DKIM signature

I personally don't agree. Any DKIM-defined assertion on behalf of the
verifier of a message is complicated. Luckily, our charter says this
pretty clearly, so to the extent that replay is an issue (and my gut
tells me it is), other anti-replay mechanisms are preferable.

Regards,
Stephen.

PS: The "personally" above, means, as usual, that as co-chair, I am
of course happy to go with the consensus even if I "personally"
disagree.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 22 Jan 2006 22:27:54 -0800

> [ab|re]using existing terms in odd ways is a bad thing.

Sorry, I was attempting to convey a concept.  The dkim-options draft
already uses the term overlay. 

> you also know that that fact is totally unworthy of mention.

As I was not including the entire table, this was to indicate that it
would be a single character combined with 'w=' such as 'w=d' or 'w=a'.
The reason for mentioning the number of added characters was to indicate
the amount of information being added is minimal.

> IMO, none of the above necessitate assertions made on behalf of

The role of the MDA is to provide anti-spoofing protection within the
MDA AdmD when signature overlays are used.  Many may not include this
added layer of protection.  The signature overlay with results however
still provides abusive replay protection.  The same role and essential
source identification scheme can be used to identify a mediator or
MSA/MUA, as well as information the signer claims to have verified.

> tells me it is), other anti-replay mechanisms are preferable.

Perhaps simple is not a good description.  The significant value that
DKIM offers is from the concise identification of the message source,
where the recipient can be assured when sources match that of a prior
correspondent.  This identification can be augmented with email-
addresses, portions of email-addresses, or perhaps opaque-identifiers.

When the binding advice within the signature indicates the email-address
has not been verified, but that the opaque-identifier has been verified
instead, this improves upon the reliability of the source information
being conveyed.  Even when the email-address domain matches that of the
signer, only the opaque-identifier may have been verified.  Of course,
nothing within the message could have been verified, and that too can be
conveyed with the binding information added to the signature.

Any additional information found within the signature depends upon the
role and reputation of the signer, where in some cases an increased
level of trust may be assumed when the email-address domains are shared
by the signature.   When the signer is not claiming the role of the MSA,
or does not share the same domain as the email-address, the level of
trust depends upon the weight given the signer.  This assumes the
verification process must consider the trustworthiness of the signer.

With respect to signing and the trustworthiness of the recipient, the
dkim-option draft provides several solutions in this area, as there is
no reason not to expect that replay abuse will not become a problem. 

Upon review of these options, compare the level of administration and
timeliness of the response required to abate an abusive replay problem
using a signature overlay strategy.   A consistent use of a signature
overlay practice allows abuse assessments to be made at the domain,
rather than at the signature or a email-address.  This closely mirrors
the same strategy used assessing the sender when receiving a message,
which is a well understood and stable.

-Doug