On Jan 12, 2009, at 6:53 PM, Murray S. Kucherawy wrote:
[Apologies for the double-send; the headers got munged by my editor.
-MSK]
Doug Otis wrote:
[...] while omitting the IP address of the SMTP client. This
prevents compliance with section 4.1 reputation check of an
authenticated message origination that is needed to mitigate highly
disruptive and injurious situations.
No, it doesn't. An implementation can be perfectly compliant in
other ways, such as doing the reputation evaluation (be it IP or
domain name) at the border MTA.
The IP address of the SMTP client, as seen at the border, may not be
captured by trace headers, nor are there reliable methods for
selecting the border traces. The goal of the Authentication-Results
header is to permit subsequent annotations based upon its content
regarding a message's origination. Section 4.1 correctly recommends
checking the reputation of the message's authenticated origination
prior to applying annotations (revealing results). Annotations
regarding a message's origination represents a critical security
function that should be treated separately from whether a message is
to be accepted.
Unfortunately, the Authentication-Results header offers no reputation
information, nor does it offer the authorization record type it relied
upon, nor does it reveal the authenticated source of the message.
Reputations of SMTP clients pertaining to what annotations are safe
can indicate whether Mail From or PRA use appears to be restricted.
This information can thereby provide non-disruptive methods to
mitigate conflicts between RFC 4406 and RFC 4408. The conflict may
otherwise lead to dangerous annotations achieved by confidence artists
that can easily take advantage of the significant difference between
offering authorization and being authenticated, and how SPF records
were intended to be used.
Ultimately, the application applying annotations must ensure the
information captured by an Authentication-Results header is supported
by the reputation of the parties involved. For Sender-ID or SPF, this
would be both the SMTP client and the inbound server adding the
Authentication-Results header. Checking the reputations of a domain
offering the authorization might provide an indication of being a look-
alike attack, but guarding against this risk is best handled at the
border MTA, or through folder placements, and not by selective
annotations as the draft suggests.
There are a lot of good reasons for doing it that way too discussed
in the draft (and, in fact, reasons not to do it elsewhere).
Reputation checks at the border are important, but they normally
pertain to whether a message is to be accepted, and seldom are about
which annotation is safe to apply.
Domain checks are unable to deal with compromised access in a non-
disruptive manner, nor can domains selectively permit annotations
based upon what the SMTP client may or may not protect. When an SMTP
client is found to not protect a particular scope, the lack of
protection may impact what is safe to annotate for thousands of
domains. However, these domains can not be readily ascertained
because SPF does not offer reverse listings. :^(
Placement within the authentication header has been made dependent
upon an undefined and unsupported notion as to whether a local-part
had been used to obtain authorization. [...]
Your assertion presupposes no SPF implementation knows, or is
capable of knowing, whether or not it expanded a local-part macro.
Even if the former is true, it's hardly a difficult thing to add,
and the user of an SPF module can easily err on the side of safety
and assume that it wasn't in either case. The normative text in
this draft covers that possibility.
Having a message noticed and read is improved by gaining greater
annotations and this represents a very strong incentive. The
currently unsupported (and fairly recent annotation qualification)
along with a natural desire to obtain greater annotation will have the
effect of promoting the use of dangerous local-part macro mechanisms.
These macros are able to generate an unlimited number of different DNS
transactions by exploiting cached SPF records. The SPF macro
mechanism offers a free DNS attack while spamming!
SM asked:
Are there any implementations of the technique you are suggesting?
The feedback received from other implementors showed that they
neither use the above technique nor do they support your point of
view.
I'd really like an answer to that question as well, since the work
in the draft is based on a number of real-world implementations that
simply don't do it the way you envision. You seem, however, to
prefer to dodge that challenge.
There are systems now that can offer feedback within a few hundred
seconds of an exploit. Without much effort, this can be tailored to
offer specific information regarding the identities used in phish that
might otherwise qualify for annotations. A dynamic reputation system
by domain would be much more perilous, since just one astray server
can affect all messages for all domains it might handle. :^(
By including the IP address of the SMTP client, a reputation check
of the SMTP client allows its Sender-ID "pass" results to be
ignored when it fails to protect the PRA.
..which could be done at the border MTA, as it has the IP address of
the SMTP client.
While a reputation check might be done at the border, this would
represent the efforts of a separate entity that makes no claim about
checking reputations, nor does the draft require this check before
adding the Authentication-Results header. Only the application
annotating the message is expected to making the check. This
represents a very dangerous loophole.
Why do you insist that there is a need to repeat at the MUA work
that's already been done at the border MTAs (where experience
suggests it belongs)?
Either the Authentication-Results header captures the IP address of
the SMTP client, and permits annotation applications a means to make
their own annotation reputation check, or the Authentication-Results
header should capture essential reputation information prior to adding
this header. A reputation indicating the SMTP client does not
restrict the use of PRA may not cause the rejection of a message.
However, this reputation information can squelch annotations without
much disruption. Unfortunately, this information is not assured to
have been checked or what needs to be checked passed on to the
annotation application. The draft was written to expect two separate
entities to:
1) Accept messages at the border (likely based on some type of general
abuse reputation), and apply methods like Sender-ID or SPF.
2) Check authenticated message origination results reputation, and
then conditionally reveal these results.
Appendix D overstates origination results reputation query concerns.
It also assumes this check will cause message rejection, rather than
affect the application of annotations as intended. Acceptance rates
at border MTAs should preclude overtaxing reputation services related
to multiple recipients within the same domain. Limitations imposed by
corporate firewalls are normally resolved appropriately (caching and
the like) by security related applications.
Why preclude an important option, and a necessary check as stated
in section 4.1? There has never been any reasonable justification
for omitting the IP address of the SMTP client. This IP address
must be passed to the SPF record evaluation process!
It's not precluded, it's explicitly required. It's just not the way
you'd like it done.
When some SMTP client allows access that "spoofs" unrestricted PRAs,
should annotations be inhibited for:
A) all domains handled by the SMTP client? (most disruptive.)
B) the domains currently spoofed (perhaps due to the misapplication of
Sender-ID.) (drafts view?)
C) all domains handled by the SMTP client until the problem is
corrected? (most effective and least disruptive.)
Importantly, the recommended remedy allows annotating a message to
remain complaint with section 4.1 which states the reputation of
the _authenticated_ origin of the message be checked first.
You seem to be reading more into that language than exists. Section
4.1 says the reputation has to be checked, but makes no assertion
that it has to be checked at the MUA. In fact, the draft contains a
substantial amount of guidance about the fact that such an
architecture is possibly even detrimental.
Applications applying annotations must make the reputation check. The
remedy being sought is to mitigate detrimental effects caused by the
omission of the origination of the message essential for the check.
Moreover, the "issues" rebuttal draft you posted contradicts
itself. For example, your section 1 claims: "While there are cases
where a domain is controlled by a bad actor, often use of the bad
domain is brief." This is an argument against your own proposed
remedy.
While reputations for a domain that offers SPF authorizations can be
acquired, these are not authenticated identifiers. Negative
reputations against unauthenticated use of a domain can prove
extremely disruptive. Blocking a problem at its authenticated source
provides the least disruption. In addition, delays while attempting
to gain confirmation of the domain's involvement is likely cause
actions to be too slow to offer protection. :^(
The claim implies that timely evaluation of reputation, i.e. when
the message is in transit, is important. Users, however, might read
the delivered messages hours or even days later. It follows that the
active part of mail delivery (the MTAs), rather than the passive
part (the MUAs), is where such evaluations must be done. Thus,
doing such evaluations when the MUA opens the message are not very
valuable. Your remedy, therefore, contradicts one of your premises.
Reputation schemes can indicate a timeframe. Not blocking at the
domain also allows affected parties to inform recipients of recent
security breaches. Blocking at the domain will not allow security
notifications from the affected domain. :^(
Finally, I'm afraid your theories about the motivations of this
draft's proponents are rather contrived.
My apologies if you were offended, although I did not make any
specific conjectures. It was tempting to conjecture, like talking to
one's self, when merits of a concern are not addressed. I'll try to
improve.
Some of the issues you brought up regarding the draft, as well as
the results of the IESG review (which dealt with guidance language
rather than technological issues), were incorporated into its most
recent versions.
You've been pushing this stuff, i.e. the remainder of your concerns,
for months now without any substantive support on any of the lists
to which you keep sending them, including during IETF Last Call
which ended more than a month ago.
Since that, the draft morphed when the draft attempted to address the
expressed concerns. For example, the conditional use of the local-
part for SPF. Unfortunately, the change is likely to have made the
problem much worse. :^(
Now, can we please, please move on?
Sorry for affecting the process, but this draft will create problems
that can be avoided.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf