On Nov 3, 2014, at 9:04 PM, Stephen J. Turnbull <step...@xemacs.org> wrote:

> Douglas Otis writes:
> 
>> After all, DMARC permits the weakest authorization as a basis for
>> acceptance, so it would be misleading to describe DMARC results as
>> having been *authenticated*.
> 
> Well, no, it isn't necessarily misleading.  According to RFC 4949,
> authentication = identification + verification, while authorization is
> a permission to do something.

Dear Stephen,

Since SPF authorizes an often _shared_ outbound IP address, it has been 
accurately described as an authorization method.  DMaRC permits a DKIM 
signature to be spoofed and still allow a message to be accepted solely on the 
basis of SPF.  What magic turns authorization into authentication???  
Describing authorization as authentication has been an exaggeration that 
started with SenderID.  Large attack surfaces provided by often overly broad 
SPF is increasingly being exploited by botnets.

Calling DMaRC Authentication threatens victims of malefactors that gain access 
by way of SPF's fairly insecure authorization scheme which might also employ 
reverse DNS handily exploited by compromised systems.  This misrepresentation 
injures recipients misled into believing DMaRC authenticated the From email 
address, as well as senders blocked because an administrator believed DMaRC 
authenticated the identity in question, the From email address.  It has not, 
nor can it.

In addition, incorrectly defining DMARC as an authentication scheme tends to 
exclude many possible adjustments needed to safely lessen DMARC's disruptive 
impact on otherwise legitimate and desired third-party services relied upon for 
decades.  Don't let the erroneous term authentication stand in the way of less 
disruptive authorization extensions.

> For example, in DKIM "d=" identifies
> the Signing Domain and "b=" + a DNS lookup provides the data needed
> for verification.  At that point you have in fact authenticated the
> Signing Domain, and with From alignment (and the additional
> assumptions that the key is available only to the Author/Signing
> Domain and that the Author Domain authenticates users) you have
> authenticated the "authorization to use that mailbox in From."  (You
> could add a lot more caveats -- there is a lot of attack surface in
> email. :-( )  Some similar statement is true for SPF (at least under
> favorable conditions :-).
> 
> AFAICS authenticating that particular
> authorization is precisely what DMARC claims to do, although the I-D
> uses different words to say that.

Authenticating an Authorization?  Does that then make an Authorization 
authentication?

> Anyway, AIUI, the question we're trying to address in Milestone One is
> how does that affect third parties on the assumptions that (1) mail
> receivers are satisfied that DMARC does what they think it does and
> (2) such mail receivers respect "p=reject".

Removing DMaRC's disruption can be done by enabling the authorization of 
necessary exceptions.  Perhaps by way of authorizing specific domains or or 
authorizing a specific From header field group syntax.  The DMaRC WG should not 
attempt to define new From header fields as a means to enable policy 
exceptions.  This would be sweeping DMaRC problems under the rug, as any new 
header field used to replace the From header field will be eventually displayed 
to users for obvious reasons.  Such expected change would provide the effect of 
re-arranging deck chairs on the Titanic.

draft-kucherawy-dmarc-base is not ready, as its definitions remain seriously 
flawed.

Regards,
Douglas Otis

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to