On Oct 28, 2005, at 4:06 AM, Frank Ellermann wrote:
Douglas Otis wrote:
Allow the DKIM SSP policy assertion be referenced from the
header associated with the domain that "introduced" the
message (Resent-Sender, Resent-From, Sender, or From), and
not the domain associated with the originator (From).
Terminology issue: (2)822 uses "originator" for the set of
addresses found in From + Sender + Reply-To. For From alone
they use the term "author".
I'm not sure what you mean by "introduced", is that something
like "injected into SMTP" ? In that case neither From nor
Sender is necessarily related to the "injector", examples are
news2mail gateways or uucp2smtp relays.
While nobody has the guts to deprecate Resent-* as hopeless
it is defined in (2)822, mail territory not limited to SMTP.
RFC2822:
3.6.2. Originator fields ...
,---
| The "From:" field specifies the author(s) of the message,
| that is, the mailbox(es) of the person(s) or system(s) responsible
| for the writing of the message. The "Sender:" field specifies the
| mailbox of the agent responsible for the actual transmission of the
| message.
'---
You make good points, but I'll attempt to use generalizations made in
RFC2822. Consider allowing other headers not related to the author
as having priority for establishing signing policy. This would
permit email services like this mailing-list to exist unchanged.
Let's take this list as an example.
From: xxxxxx(_at_)xxxxx(_dot_)xxxxxx(_dot_)xx
Subject: [ietf-dkim] Resent-nit (was: Should DKIM drop SSP?)
Date: October 28, 2005 4:06:41 AM PDT
To: ietf-dkim(_at_)mipassoc(_dot_)org
Sender: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
Let's also assume that there is some repudiation advantage when
discovering a message with either an invalid-signature or no-
signature. Currently, that advantage will likely be small for
years. With a strategy that assumes RFC2822 ordering (which could be
wrong) that selects the header likely to have introduced the message,
then in the case of the message from this list, Sender gets used,
even when compliant with RFC822.
By referencing this domain's policy, it can be determined whether the
list signs their messages. In general, signing messages reduces
uncertainty when attempting to determine whether the administrator of
the list needs to take corrective action, or whether someone is
pretending to be the list server. DKIM can make that determination.
If the operator of the list indicated that they sign all their
messages, then a list-server spoof would have been dropped. A good
thing.
With the current Sender Signing Policy based upon the author (From,
as defined in RFC2822), the assertion that the From-domain signs
messages now must include "fudge." The "fudge" would indicate
whether the From-domain still allows spoofing when the messages are
unsigned, or signed by a third-party. With the "fudge" included,
some may hold the From-domain accountable for the permitted spoofed
messages, as this strategy confronts an infamous unfair scheme
attempting to base acceptance upon the email-address. (This should
sound unpleasantly familiar.)
If the From-domain reacts to being unfairly held accountable by
removing the "fudge," now messages from _this_ list are refused or
deleted. According to Jim's threat review, you are now required to
contact all the domains that receive messages from this list and ask
that they white-list the IP addresses of the list-server, as you did
not really want to see messages from this list-server rejected or
deleted. How do you know who the receiving domain are, and what are
the IP addresses used by the list-server? (This should sound
unpleasantly familiar as well.)
If the policy were based upon the domain most likely to have
"introduced" the message into the email transport system per RFC2822,
then these email services are not disrupted and there is no need for
"fudge" in the signing assertions, and unsigned messages can be
repudiated. The more "fudge-free" assertions that exist, the greater
the amount of unsigned-message repudiation is possible.
So that's also not necessarily the "SMTP injector". For SMTP
only a non-empty Return-Path is always related to the "SMTP
injector".
It would also be reasonable to use the Return-Path.
For this list, it would be:
MAILFROM: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
The cases where the Return-Path is null would be in regard to DSN
messages. The DKIM signature would not be expected to survive in
these cases. Adding a signature to the Return-Path local-part offers
value. Perhaps there could be methods that incorporate the Message-
ID into the local-part signature, where some limited number of DSN
messages could be established as a means to discourage replays.
The opaque-identifier could be an option readily available
IIRC Keith also favours that idea. I prefer the "harden the
Return-Path" strategies, but obviously some folks are unwilling
to pay the price for that, and try to invent a new opaque
identifier protected by DKIM. We won't know what's the better
strategy for many years. All we can do here is get it right.
Apparently you think that some SSP ideas are for DKIM, what PRA
was for SPF, not good enough and unusable "in the real world".
As these unreasonable policies currently require:
A) Several complex DNS records be parsed in sequence; more will be
added.
B) Mailing-lists, e-invites, etc. must assert their From email-
address.
C) Only provider related email-addresses are permitted.
These policies will not reduce spam, phishing, or any number of bad
acts in spite of the hype.
A "fudge-free" signature policy assertion may provide a minor amount
of value when based upon "introduction" headers or even your Return-
Path. This is confronting a ridiculous situation where commonly used
MUAs shows only the "pretty-name". I lost a bet when I first saw
this and said they would only do this when confirmed by content in
the address-book. : (
Having DKIM signatures would be useful, when the message appears to
be from a phished target based upon contained URLs or deceptive
"pretty-names". A service that permitted a single lookup of these
links and domains that returned a record when the queried domain is a
phishing target would be far more practical than label-tree walking
up the bad-guys domain to find some complex stone soup policy. A
specialized service would allow immediate and substantial phishing
mitigation.
Imagine a zone that looks like:
*.<attacked-domain-a>.phished.ftc.gov.
*.<attacked-domain-b>.phished.ftc.gov.
...
Why should it be considered a reason to reject or delete a message
when the signature-domain is not within some email-address?
2.9 Verifier Acceptable Third Party Signature ...
,---
| Verifiers SHOULD NOT accept signatures from identities
| that have no known relationship with the message other than their
| appearance in the "DKIM-Signature" header.
'---
A problem that DKIM will need to deal with will be invalid signatures
of valid messages mixed with throw-away domains. Retaining the
history of the successes of signatures is likely needed for the Q of
the system to high enough to allow reasonable actions. With that
considered, then sending policy included directly within the message
provides several benefits. It does not require higher overheads to
obtain these policies. This method will also likely be more secure,
as this information is signed.
I'm not sure, but "somebody said 'Resent'" is an indicator for
all kinds of ratholes. Maybe we could avoid this by a decree,
exclude Resent- somehow from DKIM, or publish a guerilla draft
"updates 822 and 2822: Resent-* deprecated in favour of MIME".
With Resent-* removed from the picture it could be all simple.
The value of unsigned or invalid signature repudiation takes this
issue down into the noise. I would have no problem declaring either
MAILFROM or a selection of Resent-Sender, Resent-From, Sender, or
then From as the domain that establishes policy. I still insist
retaining a history of successful signatures will be required for a
reasonable Q, where policy should then be included within the
signature. This removes the concerns related to the mayhem that is
sure to surround a myriad of directions that SSP will take. Just say
no. : )
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org