mail-vet-discuss
[Top] [All Lists]

Re: [mail-vet-discuss] -19 of draft-kucherawy-sender-auth-header

2009-01-13 22:16:30

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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>