On Sep 18, 2006, at 5:27 PM, Frank Ellermann wrote:
Douglas Otis wrote:
DKIM is unrelated to the message envelope
True, more below.
Requiring the 2821.Rcpt To to match a 2822.To or CC header field
email-address is not practical.
Of course, anything not matched is by definition a BCC.
Any assumption that a DKIM signature can be used as a basis for
acceptance or rejection introduces very serious denial of service
issues.
It's THE job of SSP to change this.
Strict policy can not be applied for normal use. Only strict
2822.From policy can act as a basis for rejection, but this does not
permit non-compliant services that will continue to be used for a
long time. In addition to the 2822.From domain setting a strict
policy, the receiver must also hunt for 2822.From policy for each
2822.From email-address. In the normal case, there will not be any
policy record. The distribution of 2822.From email-addresses is
greater than that of sending agents. Even when a record is
published, the effort represents a sizable burden upon the receiver
in terms of resources, where seldom would there be any actionable
information obtained that could resulting in blocking anyway.
Annotation allows this process to be much more selective, and affords
greater and more secure protections.
Or maybe ONE job, this algorithm transition stuff is also relevant,
but I don't care where and how it's done (as long as Phil says that
it's okay).
It is my understanding the powers-to-be decided coping with
transition is not needed at this time. Store and forwarding
protocols do not allow for negotiations, which necessitates
conveyance of deprecation information.
The DKIM signature does safely permit the following when a signing
domain has been designated by an email-address:
[...skipping annotation...]
- Safe DSNs based upon 2821.Mail Froms.
No, as you said above "DKIM is unrelated to the"..."envelope".
Policy can be applied just as easily to the 2821.Mail_From in
addition to the 2822.From. A label of the associated signed-domain
could be base32 encoded as a SHA-256 + CRC32c to ensure a
deterministic 58 octet label size. Any different domain would be
required to satisfy two different algorithms simultaneously, where
the possibilities should be sufficiently small.
<base32 SHA-256 + CRC32c>._DKIM-mf.<mail-from domain>.
To avoid abusive DSNs to innocent bystanders you always need a
verified Return-Path. Minimally you've to trust that it's no
nonsense (e.g. if it came from a source where that's hopefully
guaranteed).
When the 2822.From is associated with that of the signing domain via
DKIM-MF policy, the 2821.Mail-From is assured and can be safely used
in a DSN.
If you think that _DKIM_ (not the cases discussed in 4408+4409)
safely permits safe DSNs I'd like to know how that's supposed to
work. IMO it simply does not allow this, and that's no bug or bad
thing, it's a consequence of the "unrelated" (to SMTP).
This is something DKIM-MF policy can safely provide. RFC4408 enables
various DDoS and DNS poisoning attacks as previously described.
However, a single record policy as illustrated above would not induce
these serious issues. The DKIM signature and the DKIM-MF policy
record provides the requisite association for safe DSNs. In lieu of
RFC4408, DKIM safely improves a chance of receiving a DSN, which is
when the DKIM-MF policy might be checked.
There should be a general understanding of the futility and perils
using a DKIM signature as a sole basis of acceptance or rejection.
If a policy makes 2822-compatible statements about signatures, then
using it isn't futile or perilous. Nobody's forced to publish
dangerous policies, nobody's forced to evaluate them, this is a
completely voluntary business, same idea as SPF (or SenderID,
modulo its known IAB-appeal IESG-note fine print).
There is a broader issue being missed. As with SPF et al, the desire
was to bring accountability to the originator. Just as with these
other protocols, this will not work with DKIM either for the same
reasons. From our data, rejections based upon a "soft-fail" + "fail"
only block about 9% of spam, while also imperiling DNS
infrastructure. When based upon just the "fail" as commonly required
to avoid delivery issues, less than 3% of spam is blocked. The DSN
DDoS concern can be addressed using DKIM and a 2821.Mail_From DKIM
policy record as described above without incurring genuine risks or
violating proprietary algorithms. To prevent spoofing, nothing beats
annotation of retained email-addresses.
Abuse MUST be handled by identifiers tracking the actual sending
agent.
Maybe, but that's not a "MUST" for SSP reqierements, it belongs
into another document like 2821bis or BASE.
For the policy requirements, the desire to have customers provide
delegations to their provider completely overlooks this MUST
however. Here policy based associations would be vastly safer. As
Olbermann would say, the batteries are in backwards; designations are
significantly safer than delegations. In either case, the signing
domain must be trusted to act based upon the 2822.From address by
limiting the account and selecting the signing-domain. With DNS
delegation, the provider must be trusted to use the correct signing-
domain which imposes far greater risks. In any realistic way of
evaluating risk, DNS delegation increases risks for the 2822.From
domain. It would be desirable to have had semantics defined that
allowed the provider to explicitly assert which email-address had
been restricted, but that information can also be deduced by a
2822.From policy association as well. Designation simply imposes
different provider expectations.
In either case, the provider is being trusted when designation or
delegation is used. There is far greater risks for both the provider
and the 2822.From domain owner when a DNS delegation method is used.
With DNS delegations, the provider may not see abuse reports and the
2822.From domain owner may be attributed for having signed messages
they did not originate, and will not have logs to prove otherwise.
That are the underlying security concerns related to some email-
address policy and how can security be generally improved upon by
this policy?
Isn't that already covered by the threats RFC ? For the "SSP
requirements" it would be a waste of time if it tries to list all
potential security considerations of a future SSP proper.
The threats draft missed that the sending agent must be held
accountable and that the DKIM signature can not play this role. As a
result of this oversight caused by understatements of replay concerns
among others such as use of annotations, the threat draft offers poor
guidance for the policy effort. The policy requirements draft
appears to be a continuation of this short-sighted view. : (
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
