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