On Jul 10, 2008, at 12:59 PM, J.D. Falk wrote:
On 10/07/2008 13:10, "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org> 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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html