Subject: [ietf-dkim] identity vs domain, battles of years past, and bot-nets.

From: Douglas Otis <[email-masked]>
Date: Thu, 10 Jul 2008 12:10:50 -0700

Over DKIM's development span, bot-net behaviours have changed and are  
becoming more stealthy.  Much of this change may be in reaction to  
greater proportions of IP address space being blocked.  As a result,  
an increasing proportion of bot-net originated spam is sent through an  
ISP's outbound server by exploiting accounts obtained from bot-net  
0wned customer's machines, rather than directly from the 0wned  
machine.  Unfortunately, ADSP's current Author Signature definition  
depends upon the ISP either affirming the identity of the Author or  
leaving the "on-behalf-of" identity blank and ambiguous. This is a  
tragedy.

Bot-nets are related to accounts held by 0wned machines that often  
serve more than one individual.  The current definition of the Author  
Signature will necessitate a change in how access to outbound services  
are obtained to conform to a the Author Signature definition that  
requires an author's identity to be affirmed or left blank.  Instead,  
the "on-behalf-of" identity parameter should be able to indicate how  
the outbound service was accessed and thereby accommodate today's  
diversity of access solutions.  In addition, it should be possible for  
the ISPs to obfuscate this "on-behalf-of" indicator to better protect  
the privacy of their customers, while at the same time enable third- 
party feed-back as to the source of their intra-domain bot-net problem.

It is extremely important not to confuse the domain seen in the author  
email address, with that of individual authors.  Although DKIM allows  
a domain to authenticate and affirm an Author Address using the "i="  
parameter, this is just an option.  The Author Address (local-part)  
and the domain must always be annotated separately when some assurance  
is shown to recipients.  The need for a separate annotation of local- 
part and domain is not affected by changes to the Author Signature  
definition.  ISP's should be allowed to advertise that they sign every  
outbound message without causing their signatures that indicate an "on- 
behalf-of" identity reflecting an account rather than an Author  
Address from being considered invalid with respect to ADSP  
compliance.  Conversely, it would be negligent to annotate or treat a  
message as being signed when a key with a restrictive local-part  
template fails to match against the Author Address regardless of any  
ADSP advertisement.

Jim has suggested that providers can add multiple signatures whenever  
they have a desire to indicate an "on-behalf-of" identity that is not  
that of the Author Address.  Unfortunately such requirement would  
increase the average message size, and double DKIM's resource  
overhead.  In other words, Jim's suggestion is simply not practical.   
The current Author Signature definition will result in DKIM being much  
less effective against an ever growing bot-net problem.  Bot-net 0wned  
machines are not just a threat to email, they threaten all aspects of  
the Internet.

DKIM can be effective against this menace, but only when the "on- 
behalf-of" identity is allowed to reflect how access to the outbound  
service was obtained.  This change will still inhibit phishing, and  
when access is dependent upon the authentication of the Author  
Address, this too can still be made apparent regardless of the Author  
Signature definition.

-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 10 Jul 2008 13:59:22 -0600

> leaving the "on-behalf-of" identity blank and ambiguous. This is a

It's only a tragedy if your only goal is to easily catch botnet-sourced
spam.  That may be a goal for Trend Micro, and it's been a goal of mine, but
I'm pretty sure it's never been a goal for DKIM.

The access method classification assertions you suggested (which I didn't
quote) don't need to be part of DKIM, because they'll be equally valid and
equally useful for non-DKIM-signed mail.  If you're going to pursue this,
I'd strongly urge you to do it as a separate, standalone project.  DKIM can
make that project stronger, and that project may make DKIM useful in more
areas, but neither goal requires the other to succeed.

-- 
J.D. Falk
Return Path

Work with me!
http://www.returnpath.net/careers/

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Jul 2008 21:20:12 +0100

Douglas Otis wrote:
> This is a tragedy.

This is not the time for any kind of drama for ADSP, whether
in 3 acts or not;-)

If you have a concrete proposal please send exact text that
can be edited into the document.

I'd ask people to not debate this (again) in the absence of
both a) such a concrete proposal *and* b) declared support
for that proposal from at least a few other participants.

Thanks,
Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 10 Jul 2008 17:50:23 -0700

On Jul 10, 2008, at 12:59 PM, J.D. Falk wrote:

> It's only a tragedy if your only goal is to easily catch botnet- 
> sourced spam.  That may be a goal for Trend Micro, and it's been a  
> goal of mine, but I'm pretty sure it's never been a goal for DKIM.
>
> The access method classification assertions you suggested (which I  
> didn't quote) don't need to be part of DKIM, because they'll be  
> equally valid and equally useful for non-DKIM-signed mail.  If  
> you're going to pursue this, I'd strongly urge you to do it as a  
> separate, standalone project.  DKIM can make that project stronger,  
> and that project may make DKIM useful in more areas, but neither  
> goal requires the other to succeed.

The suggested change for ADSP related to this thread can be found at:
http://mipassoc.org/pipermail/ietf-dkim/2008q3/010630.html

This suggested change is fairly small.  The change to ADSP allows the  
"on-behalf-of" role defined in RFC4871 be retained.  The current ADSP  
draft defines signatures as non-compliant (invalid) that use the "on- 
behalf-of" parameter as allowed by, and as a goal of, RFC4871.  Why  
wait years for a separate effort to restore the role of the "i="  
parameter?  Why does ADSP insist on declaring otherwise valid  
signatures as non-compliant?  This will cause interoperability issues  
at least.  ADSP currently demands that, for compliance, signatures  
affirm the local-part of the Author Address or remain silent about  
it.  Will authors of the draft provide their reasoning for this  
critical decision?

It would be a grave mistake to only consider restrictive local-part  
templates with respect to ADSP compliance, and a graver mistake to  
invalidate signatures made by Trusted signing systems on the basis  
that the "on-behalf-of" is not an Author Address.  Signature  
validation MUST preclude messages having restrictive local-part  
templates where the corresponding "on-behalf-of" is not also an Author  
Address.  This case must not be allowed to slip through a signature  
validation crack.  Signatures by an Untrusted signing system (with  
keys that have restrictive local-part templates) will be required by  
RFC4871 to have the "on-behalf-of" parameter match against the key's  
local-part template.  A message with a restrictive local-part template  
where the corresponding "on-behalf-of" is not an Author Address will  
be deceptive whenever the message is annotated or treated as being  
signed.

These messages would likely represent stolen keys being exploited,  
since the Author Addresses would not be controlled by Author Domains.   
Making the recommended change can preclude very likely exploits, while  
also greatly increasing DKIM's protections.  This change will not  
limit the use of DKIM signatures by Trusted systems.  Keys with  
restrictive local-part templates are likely used on vulnerable mobile  
systems prone to theft.  Where a restrictive local-part template's  
corresponding "on-behalf-of" is not an Author Address, the signature  
MUST not be considered valid, which is what the current Author  
Signature definition almost does.  Signature invalidation based upon  
restrictive local-part templates should be independent of ADSP  
assertions and compliance assessments.

The revised definition ensures a message containing an Author Address  
is signed by a Trusted system controlled by the Author Domain.  Any  
system lacking a local-part restrictive template in the key is clearly  
Trusted to sign on behalf of the domain as a whole.  The signature now  
being declared by ADSP as being non-complaint (invalid) might  
represent that of an office administrator issuing a message authored  
by their supervisor, who also has an address within the same domain,  
but where the administrator's address has been authenticated and is  
properly found in the Sender header, rather than the From.

A Trusted signing system must decide whether the office administrator  
is permitted to issue the message, even where the "on-behalf-of" "i="  
identity is left blank, as currently required by ADSP, but not by  
RFC4871.  This type of consideration should always be made prior to  
signing.  Obligations of Trusted signing systems have little to do  
with what is not indicated by "on-behalf-of".  The simplistic approach  
of "on-behalf-of" always matching an Author Address or being absent  
for ADSP compliance, but where this check is not part of signature  
validations of restrictive local-part templates, opens security flaws  
and interoperability issues.  Once this flaw is repaired in ADSP, use  
of the "on-behalf-of" parameter can be restored to RFC4871 definitions.

The current ADSP Author Signature definition makes it impossible for a  
single signature to express who or what was authenticated by "on- 
behalf-of".  The What is never allowed by a single signature, but in  
reality, the What is likely more important than the Who.  Whats are  
often 0wned.  Getting this wrong, at this late date, is a shame since  
it means many more will remain in harms way of a very real bot-net  
menace for a long time.  If this is not a tragedy, it is not far from  
it.  At least there should be a record as to why the "on-behalf-of"  
parameter must be blank, or match that of an Author Address for a  
signature to be considered ADSP compliant.  There should also be a  
record as to why restrictive local-part templates and "on-behalf-of"  
considerations do not play a part in signature validation, but instead  
are just an aspect of ADSP compliance.

-Doug