[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    Re: [mail-vet-discuss] -19 of draft-kucherawy-sender-auth-header
From:       Douglas Otis <dotis () mail-abuse ! org>
Date:       2009-01-14 3:15:42
Message-ID: 179586DC-25BF-4389-8002-2A1EF99D69C5 () mail-abuse ! org
[Download RAW message or body]


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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
[prev in list] [next in list] [prev in thread] [next in thread]