Re: [spfbis] Review of draft-ietf-spfbis-experiment-05

[Douglas Otis <[e-mail]>]

On 4/23/12 8:13 AM, Dotzero wrote:
> On Mon, Apr 23, 2012 at 10:34 AM, Murray S. Kucherawy<[e-mail]>  wrote:
>>> -----Original Message-----
>>> From: Dotzero [mailto:[e-mail]]
>>> Sent: Monday, April 23, 2012 5:58 AM
>>> To: Murray S. Kucherawy
>>> Cc: [e-mail]
>>> Subject: Re: [spfbis] Review of draft-ietf-spfbis-experiment-05
>>>
>>> It is absolutely incorrect to say that their accuracies are about the
>>> same. I can consistently game PRA to get a neutral outcome regardless
>>> of what the originating domain publishes in it's record. If there is a
>>> Sender field then that is the PRA per the spec. I cannot do the the
>>> same for SPF.
>> Based on the data collected about actual live mail streams, SPF and Sender ID reach the same pass/fail conclusion about messages at least 80%, and as much as 95%, of the time.  Do you have different data?
>>
>> We're specifically not doing a comparison of the weaknesses of the two.  We're only citing empirical data.
>>
> You stated that their accuracies are comparable. Given the known
> weakness of PRA (based on emperical data/testing), that is an
> incorrect statement. The whole point of SPF (and presumably SIDF) is
> to mitigate abuse. You have not provided complete details about the
> dataset you are referring to so it is hard to draw detailed conlusions
> regarding key points:
>
> 1) What percentage of the dataset does not have a Sender field?
> 2) For data points where there is a Sender field, what percentage of
> those data points have a Sender field that is aligned with the Mail
> > From (and conceivably From)?
> 3) What percentage of the messages were "abusive"? Would the mail
> stream selected be a likely target for the particular type of abuse I
> am pointing out? If not, why would you expect to see this particular
> type of abuse?
> 4) To what extent is the dataset representative of the mail streams
> that various types and sizes of receivers might receive? That is, is
> the dataset truly representative or are there potential issues with
> self selection, etc?
Dear Mike,

Agreed.  Serious security concerns remain.  Publishing domain alignments 
of various message elements might better illustrate these concerns.

Both PRA and Mail parameters suffer similar weaknesses as neither are 
assured to be visible.  Unlike the PRA, the Mail parameter establishes 
the return-path, however SPF records lack any assurance which identity 
is intended to correspond with outbound server addresses.  Instances 
where PRA accommodates normal SMTP function (without misuse of Resent-* 
header fields) allows this scheme to be more compliant.  This compliance 
carries added risk as it requires application of similar out-of-band 
information necessary for making exceptions as those with the Mail 
parameters, although the Mail parameter offers less selection 
uncertainty and much less associated overhead.

The SPF HELO/EHLO option does not require use of out-of-band 
information, does not require exceptions, nor is there more than one 
possible identity within a message exchange.

While HELO/EHLO identity is recognized by SPF, SPF lacks a scope list 
making it clear whether use was intended exclusively for the HELO/EHLO 
to authenticate outbound servers, or to authorize third-party servers 
that might carry a domain's messages.   Source authentication using 
HELO/EHLO offers content assurances lacking with either the PRA or Mail 
parameters.  Additionally, only the HELO/EHLO identity is able to ensure 
messages not directly originating from their servers can be safely 
rejected, which to prevent spoofing,  requires a separately specified 
 From header field alignment requirement.  IMHO, the situation faced 
today would have been better resolved by agreeing to a scope-id list 
that included MFROM, PRA, and HELO.

The PRA and Mail parameter identities are used to guess whether a 
particular server may have been authorized to issue the message or 
whether the server is normally not compatible with either scheme.  
Clearly, this lacks a solid basis for ensuring message interchange.  By 
not holding the outbound server accountable for issuing spoofed 
messages, users that have had their accounts compromised are less likely 
to be made aware of this dangerous situation and there is less incentive 
for ensuring account security.

Regards,
Douglas Otis