On Jun 27, 2008, at 1:00 AM, Frank Ellermann wrote:
Douglas Otis wrote:
The DKIM/ADSP DDoS concern is analogous to that of Sender-ID.
ADSP needs at most one DNS query for an existing domain, there is no
"analogy" to spf2.0/pra. If you are worried about a From header
field with hundreds of addresses below a victim domain we write
"don't do this" in the ADSP security considerations.
Briefly, Sender-ID enables an exploit for bad actors that are able to
influence the PRA. This exploit allows ten target-able transactions
per received message using virtually none of their own resources,
beyond that used to issue the message to provider's outbound servers.
The size of the attack could be further increased when bad actors use
their own resources to issue DNS records, but with an amplification of
10 or more. So how can ADSP/DKIM be analogous you ask.
ADSP is about accepting messages when there is no valid Author Key
Domain signature. There still may be signatures contained in the
message. While it will be unusual to have multiple From header email-
addresses, having multiple DKIM signatures will not be. This means a
message may be expected to generate several additional target-able
transactions made by receiving hosts and MUAs who evaluate DKIM
message signing. Of course, unsigned messages are limited to
transactions needed to discover ADSP records. The otis-dkim-adsp
draft requires one compared to SSP-03 draft's of three discovery
transactions. The SSP-03 additional transactions was to reduce the
number of records a phished domain feels they need to publish. John
Levine's replacement for this also uses three. With all the undesired
transactions spewing from SMTP receivers, IMHO, only the MX record
should ever be checked or the Internet will suffer.
There will also be at least one target-able transaction for each
signature validation attempted. The SSP-03 draft _requires_ multiple
signatures to comply with its definition of a valid signature whenever
a domain wishes to indicate an on-behalf-of identity that is not the
Author Address. This identity might be found in the Sender or Resent-
From header for example. It is hard to predict the future use of
multiple From headers. The number used could be influenced by email-
address internationalization or DKIM validation constraints. Allowing
even one additional From email-address will have DKIM provide a number
of free target-able transactions that approach that of Sender-ID. Of
course, there is still going to be Sender-ID transactions made when
DKIM fails, for domains that do not have a LOCKED ADSP record. : (
Sender-ID allows an override by version 2
As always your hermetic terminology beats me. spf2.0/pra is one of
five existing tags (or subtypes) for SPF records, and three of them
are in practice pointless:
v=spf1 RFC 4408, about SMTP HELO + MAIL FROM
The breakdown needs to include the PRA for this version as well. The
experimental RFC4406 (Sender-ID) made a point to include "v=spf1".
The Microsoft's documentation clearly promotes Sender-ID without
warning about potential DDoS concerns or record misuse. It blithely
touts the number of organizations (with large networks) evaluating
PRAs per their recommendations. This would not be the first time
potential misuse of a macro expanded record was, with malice of
forethought, overlooked. : (
There is no such thing as an "override by version 2" for PRA, and
the four subtypes in Sender-ID all start with "spf2.0", if you
consider that as "version 2".
The version 2 reference was for RFC4406 "spf2.0/<scope list>" records
having otherwise the same syntax as version 1. Version 2 might
override the scope defaulted by RFC4406 for version 1 to prohibit PRA
evaluation, but it seems doubtful a provider would do so, nor is there
a means to really ensure PRA exclusions.
The relevant concern is whether a bad actor can influence the PRA
Bad actors pick whatever PRA, 2822-From, HELO, or MAIL FROM suits
them. It's the job of v=spf1, spf2.0/pra, or ADSP to defeat that.
The issue is about target-able undesired traffic that bad actors
generate when exploiting both receiving host and recipient resources.
When evaluation proceeds until something acceptable is discovered,
then cases that generate undesired traffic that could be part of a
distributed attack are likely ignored.
And because spf2.0/pra works only at border MTAs, with the known
limitation of v=spf1 for SMTP forwarding, *plus* new requirements
for any forwarder and mailing list to update the PRA (i.e.
manipulate the message proper, not only the envelope), *minus* the
advantages of v=spf1 for a PASS, it might turn out that sp2.0/pra is
"less sexy" than ADSP for receivers. Or maybe not, we'll know that
in some years...
The Internet should not be held hostage by bad actors exploiting
poorly considered authorization or authentication schemes. Retaining
a functional email system and Internet depends upon behavioural
tracking. This tracking could be dramatically improved when it can
reliably recognize bot-net 0wned systems. This tracking should not
need to depend upon the deep pockets needed to sustain reception of
undesired traffic generated by poorly considered authorization or
authentication efforts. Unfortunately, SSP-03 fails to consider what
might occur when dealing with bot-nets, and likely source of undesired
traffic, and how it can mitigated. Unfortunately, this is a real
problem.
Of course, bad actors would also have their messages receive a
Sender-ID and/or MAILFROM PASS authorization.
Or an ADSP signature. Bad actors do with their addresses what they
like, the idea of v=spf1, spf2.0/pra, or ADSP is that they can't do
this with FAIL-protected addresses (for FAIL read "suspicious",
"locked", "discardable", or the term du jour used in ADSP).
Agreed.
BTW, a MAIL FROM PASS is no "authorization", it only means that a
bounce will hit a party responsible for publishing a PASS-policy for
the relevant domain.
At least I am not calling it Authentication as you know who does. : )
Receivers can use a PASS or "good signature" to mean more in
conjunction with a white list or reputation system, but that is
entirely under their control. A PRA PASS from an unknown stranger
means nothing, let alone "authorization". Ditto "good signature"
from unknown stranger.
Agreed.
A customer's message determines the PRA in various ways where
macros, rather than DNS records directly, might do the bulk of the
damage.
There is exactly one way to determine the PRA, and it is specified
in RFC 4407, for folks who don't find the very simple idea in
2822upd. The evaluation of spf2.0/pra has exactly the same
processing limits as v=spf1 in RFC 4408, by a normative reference in
RFC 4406.
RFC 4406 boils down to "maybe using the RFC 4407 PRA would be cute,
instead of a 2821bis MAIL FROM". This "hack" is so lousy that it
does not even bother to specify what to do with a 2821bis HELO and %
{h} macros - an integral part of RFC 4408, but an oddity in the
context of PRA. Ignore spf2.0/pra, like most folks not forced to
care about it.
Unfortunately, bad actors are able to exploit providers that do not
ensure PRAs are not influenced. : (
That ADSP fails miserably for Resent-From scenarios, and arguably in
violation of the 2822upd e-mail architecture, that is interesting
for this WG.
Except for the few situations where a LOCKED ADSP record might be
used, ADSP only helps email filters make better guesses about these
issues. Would you see that as a failure?
IMHO anybody trying to outsmart RFC 4407 so far dropped the ball,
including ADSP, but "you" want to try it anyway, let's see what
happens...
Phishing or spoofing prevention must be based upon something a
recipient sees, or can use for folder placement. Basing a protection
scheme on something like PRA creates the same phishing holes that
Sender-ID has. The basic premise is that only a few domains will
assert LOCKED ADSP records. Sender-ID and PRA requires a mail filter
to somehow know which From/Sender headers are likely phished.
However, not all MUAs even display the Sender field or for that
matter, the email-address itself. A bad actor is able to use Resent-*
and sometimes even Sender headers to have their messages accepted with
a Sender-ID PASS and still deceive a recipient.
ADSP, on the other hand, takes a different tact. Since a mail
filtering engine is still needed, ADSP provides filter information
about the initial state of a message. When the domain asserts a
CLOSED ADSP record, then a mail filter is likely to expect evidence as
to why a signature is now missing or invalid. The filtering can then
weigh the strength of that evidence. Even without a mail filter,
there is also annotation. Messages from a trusted domain with a valid
signature can be annotated, while those messages without a valid
signature would not receive the annotation. It seems ADSP provides a
simpler and safer scheme for protecting recipients.
The otis-dkim-adsp draft does not dictate which local-part identity is
to be included within the signature. It indicates the domain's
practice assertion pertains to messages where this domain is within
the From header.
Freedoms are lost due to Sender-ID exploits.
...even if that would be the case, what has it to do with ADSP or
DKIM ? ADSP "eliminates the Resent-From freedom" and violates
282upd. So what, there is already an appeal against a similar issue
in PRA on public record. And in comparison PRA was harmless, ADSP
is a frontal assault on 2822upd Resent-*.
Are you suggesting ADSP should be be based upon PRA handling? Please
note that the DDoS and bot-net tracking concern has nothing to do with
what field a practice assertiion is based. The desire is to ensure
that a direct DKIM signature indicates the signed on-behalf-of
identity, and not that it be considered invalid when this identity is
not that of the Author. The domain and not the author is what people
are likely to trust, and when the domain's signature affirms the
identity of the Author, the Author can obtain some "special"
annotation. Hopefully ADSP will not limit one's ability to include
other headers, except in rare cases where a domain publishes a LOCKED
ADSP record.
We know this. Repeating it for the 1001st time is boring, let's
keep our ammo for the IETF Last Call + appeal(s).
It is hard to kill such a well funded and well promoted experiment
gone bad...
Some people in the WG seem to have difficulty accepting that DKIM/
ADSP is not about making strong assertions of the author identities.
IMO it's more like "some people consider DKIM as pointless without
strong assertions", because they don't send the volume of mails to
make their DKIM signatures interesting for white listing by
important receivers (including cases such as ironport).
Without the chance to reject mails checking signatures of unknown
strangers is not very interesting for receivers.
A LOCKED ADSP assertion would permit the rejection of emails. It
would not be surprising to find DKIM is only checked when there is
such an opportunity, since this assertion would be a strong indication
of there being a problem DKIM is attempting to solve. The identity of
the author would be completely irrelevant, since whoever the author
might be, whether there is a signature added is what matters for the
message to be dismissed.
RFC3834 allows content of the message to be eliminated in most cases.
That's not the case. If some POP3 users dig through the backscatter
with TOP they'd still have to deal with the header. Let's say that
worldwide adoption of RFC 3834 Auto-Submit is "not yet ready", and
besides folks want also the body of good (= no backscatter) auto
replies.
Sorry, the concern is about including the original spam, and not that
of an auto-reply. False positive rates should be low enough to
protect these types of messages.
Had this problem been dealt with by the IETF instead of closing the
WG, what remained would likely have meet most of your expectations
safely.
Maybe, or as Wayne said, a huge mistake. I let the AD talk me out
of an appeal, because I had no idea for a "remedy" (hours after I
figured out that there is an appeal procedure, as expected, and an
RFC specifying the proper procedure to terminate an IETF WG).
That's now ancient history, R.I.P.
As with laws and sausages, specifications seem to fall into the same
category as things that people should not watch being made.
Some may consider a DSN that does not adhere to RFC3834 and that
includes the original spam to be treated as if the client
originated the message
Just in case: RFC 3834 is a PS about auto-replies, not about DSNs
(3461..3464, DS), and not about MDNs.
All use the envelope sender address of the alleged sender, typically
with an empty return address in their various "auto" activities.
For DSNs replace typically by MUST, loops are bad.
You are right, but RFC3834 is a nice reference since it links to more
specific RFCs regarding the other types of responses.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html