Re: [dmarc-ietf] The DMARC WG has placed draft-crocker-dmarc-sender in state "Call For Adoption By WG Issued"

[Doug Foster <[e-mail]>]

-1
A vote against the proposal in the strongest possible  terms.

About the Analysis:

Quote
Internet mail defines the RFC5322.From field to indicate the author of the
message's content and the RFC5322.Sender field to indicate who initially
handled the message...  This was not a problem, until development of
stringent protections on use of the RFC5322.From field.  It has prompted
Mediators, such as mailing lists, to modify the RFC5322.From field, to
circumvent mail rejection caused by those protections.

Comment
The author fails to recognize that we have a single-author email
architecture.  Consequently, the last entity to alter the message IS the
author.  An altered message can be compared to a Hollywood movie that is
"inspired by real events."   The delivered message probably has a connection
to what the originator wrote, but the nature of that connection is unknown
to the recipient.   DMARC forces the true author (the mailing list) to take
ownership of its work by using a From address in its own domain. 

Quote
This affects end-to-end behavior of email, between the author and the final
recipients, because mail from the same author is not treated the same,
depending on what path it followed.  In effect, the RFC5322.From field has
become dominated by its role as a handling identifier.

Comment
This is factually wrong.  The path that a message follows has always been of
interest, because the reputation of each handler is relevant to the risk
associated with the received document.  DKIM signatures provided a
technology to address this problem.   If and only if a DKIM signature can be
verified, then the receiver can conclude that the path is irrelevant to
message risk.   For the problem at hand, messages are assumed to originate
with a valid signature, so path would not matter if the document was not
altered.   It is the mailing list action to alter the message which alters
the risk profile of the message, not the path followed. 

Document alteration is an inherently untrusted activity.  The ability to
make constructive changes is also the ability to make malicious changes.
The ability to make changes is also the ability to create entirely new
messages, because a new message could be fabricated to look like a forwarded
message if it was advantageous to an attacker to do so.   Mailing lists want
recipient systems to conclude that the mailing list will only make
constructive changes.   This is an administrative decision which cannot be
obtained from the document itself.   It must be obtained using an
out-of-band process, and it must be obtained from each recipient, or from
the originator domain using a process that each recipient domain will trust.
   
This document proposes a way for recipient domains to authorize exactly what
mailing lists wish to do.  The proposed protocol would grant that trust if
both originating and sending domains choose to participate.   But the stated
path sensitivity is a misrepresentation of the situation.

Quote
The current specification augments use of the RFC5322.From field, by
enhancing DMARC to also use the RFC5322.Sender field.  This preserves the
utility of RFC5322.From field while also preserving the utility of DMARC.

Comment
As we shall see, this proposal has the effect of rolling back DMARC, not
preserving it, for any domains that choose to enroll in it.

Quote
Because the current email protection behavior involves the RFC5322.From
field, and pertain to the human author, it is common to think that the
issue, in protecting the field's content, is behavior of the human
recipient.  However there is no indication that the enforced values in the
RFC5322.From field alter end-user behavior.  In fact there is a long train
of indication that it does not.  Rather, the meaningful protections actually
operate at the level of the receiving system's mail filtering engine, which
decides on the
disposition of received mail.

Comment
This assertion is based on the author's inability or unwillingness to
distinguish between an author identifier and a trust indicator about
authorship identifier.  The From address is an identifier which indicates
the entity which is supposedly responsible for the content.  The reliability
of that assertion is affected by whether the connection between the author
and the document can be verified by a mechanism such as DMARC.   A trust
indicator is a symbol or text phrase which indicates whether verification
has been successful or not.   As discussed in the WG, trust indicators have
some effect on user behavior, but not the dramatic effect one might hope
would occur.  This means that the user tends to believe that the From
address is valid, whether the trust indicator is present or not.  It does
not mean that the From address has no relevance to the user.   In general,
the user expects that the From address will be the Reply-To recipient.  A
user would be surprised and alarmed to reply to a message using the From
address, and then learn that the reply made no sense because the original
did not originate from the stated From address.

Just as importantly, the assertion is hypocritical.   The end-goal of this
proposal is to allow a mailing list to set the From address to a particular
value of its choosing, because the value of the From address is perceived as
very important to their user base.   Therefore, the reader is requested to
believe that the From address is, and should be, very important to mailing
list subscribers, while it is not, and should not be, important to anyone
else.


About the Proposed Protocol:

The proposal implements an unrestricted third-party signature delegation
mechanism.    

The proposal language obscures the fact that the original document's DMARC
validation occurs against the originator's domain, while the enhanced DMARC
validates only against the resender domain.  This change of reference is
necessary to achieve the intended goal for mailing lists, because the
list-altered message can only be authenticated using the mailing list
domain.   Since this arrangement is contrary to the design of DMARC or the
intent of the participating domain owner, it is not preserving the benefits
of DMARC at all.

Once a domain owner agrees to participate in this "enhanced" DMARC, anyone
can send messages "From" that domain, as long as the sender authenticates
itself using the Sender field and a corresponding DKIM signature.   These
requirements are trivial, and can be satisfied with minimal effort by any
sender, whether legitimate or malicious.    The combination of this
protocol, along with the enabling DNS entry, provides a guidebook to
spammers about how to successfully spoof the participating domain. 

Consequently, this configuration produces a result which is inferior to
operating with DMARC disabled.   Without DMARC, the receiving system
observes an "Not Verified" result, which tends to encourage a rigorous risk
assessment.   With this "enhanced" DMARC, the receiving system receives an
"Authorized" result, which tends to encourage a less skeptical risk
assessment.   In reality, an authorization which is available for us by
everyone is of no value to anyone at all.

Given that the "enhanced" DMARC removes the benefit that DMARC is designed
to provide, there is no reason for a domain owner to enroll in the enhanced
process, and no reason for a message recipient to accept the recommendations
produced by the enhanced process, since the enhanced process is inferior to
no process.   

In the working group, participants indicated that prior attempts to
implement controlled third-party signature delegation have been ignored or
rejected by domain owners.   If domain owners are uninterested in controlled
third-party signature delegation, why would they be interested in one that
has no controls?


About the Intended Benefits to the Mailing List

As if all of this were not enough, this proposal will not solve the Mailing
List problem even if it is implemented widely.   The proposal does not
provide a way for mailing lists to know if the recipient system has embraced
the "enhanced" DMARC or not.   As long as the implementation question is in
doubt, the mailing list would have to proceed on the defensive assumption
that DMARCv1 is still enforced.    This might produce the worst of all
possible results:   malicious sources use brute-force techniques to find and
attack those domains which accept the enhanced DMARC, while mailing lists
remain afraid to utilize the new scheme which they hoped would solve their
problem.


About Defending the Mailing List Identity

Mailing List Domains SHOULD implement DMARC to protect their subscribers.
Mailing lists such as the present one are easily spoofed, since the list is
only identified to the user by the list footer and the subject tag, both of
which are easily duplicated.    Any malicious source which has this
formatting information can produce a fake posting, apply a non-DMARC value
in the From address, and send it to any known subscribers.    The subscriber
will have no visible clues to indicate that it is not a legitimate post, and
the incoming email gateway would have no discernible reason to require that
the message come from an IETF server.  The spoof would succeed as long as
the malicious message was not blocked by a blacklist rule in the incoming
email gateway.

If Mailing List domains implement DMARC, replacing spoofed From addresses
with a list domain address, all submissions would become DMARC-verifiable
upon delivery, whether submitted by a DMARC-participating domain or not. 

There are several options for identifying the originator despite using the
list domain in the From address.   Some of these have been discussed in the
Working Group.


Summary

The proposal is without merit.

Doug Foster