Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

["Murray S. Kucherawy" <[e-mail]>]

Still as just me:

On Sat, Aug 15, 2020 at 3:34 PM Douglas E. Foster <fosterd=
[e-mail]> wrote:

> Based on the discussions here, it appears that the notion of From address
> validation was envisioned from the beginning Sender Authentication
> discussions.    We have written evidence that Form address validation was
> anticipated in the DKIM and ATPS RFCs prior to DMARC.    So we have more
> than a decade of warnings that From address validation was coming.   While
> not everybody has time to read every RFC, the Mailing List trade press must
> have should have been reporting on it as something to watch.
>
I don't follow the logic here.  DKIM, as I recall, expressly disavowed any
assertion that could've been taken as From address validation.  (I think it
was in there before RFC 4871, but we collectively decided to remove it.). I
don't know how one could have inferred imminence from that.

ATPS is an Experimental RFC.  It was meant to, in some ways, augment ADSP
when we'd already figured out the damage it could cause.  The purpose of
publishing it was to get everyone (for some value of "everyone") to agree
on a protocol to use to provide third-party signature authorizations and
see if it was a useful response.  The silence was deafening.

Even after DMARC was in use, it appears that nobody in the mailing list
> community felt inconvenienced until the AOL/Yahoo hack and their decision
> to implement DMARC with p=reject.   This was the moment of Unhappy
> Surprise.    Bad guys had obtained many valid email addresses, so one of
> the concerns was how to prevent them from spoofing those users to send
> spam.   They could not use those address in the SMTP address because of
> SPF, but only DMARC could prevent those addresses from being misused in the
> Message From address.     It was the obvious thing to do and it would have
> been reckless for them to do otherwise.   Can you at least admit that the
> mailing list community was surprised because they failed to prepare for
> this contingency?
>
I wouldn't characterize it as "failure".  If you agree that DMARC's
antecedent is ADSP, I believe it had already fallen into disfavor to the
point where nobody was really worried about it anymore.

But I would agree that nobody anticipated it, especially since DMARC itself
and RFC 6377 both warned against its use for this very reason.

[...]  As a result, mailing list operators really have no standing in this
> discussion, although they can certainly speak as unhappy individual users
> and on behalf of their unhappy users.
>
I suggest that's precisely what gives them standing.

Consequently, the real problem before us becomes the existence of users who
> are unhappy because the From address on some mail does not meet their
> preferences.    I have to ask why that is a problem worthy of a standards
> body?     I have about 8 different scenarios in my head where a user might
> be have unmet expectations with the format of the From address, or might
> experience mailing list deliverability problems because of the email
> filtering policy of its domain relative to the addressing practices of his
> mailing list.   If our requirement is to make every user happy, shall we
> head down the path of all 8 problems, not just this one?
>
If all eight problems have been raised and acknowledged by the chairs, then
I imagine the answer to your question is emphatically "yes".

Though published as an RFC, DMARC was not an IETF consensus document.  The
remit of this working group is to come to consensus on a set of changes
that qualify it for the standards track.  We do that by considering the
perspectives and issues raised during that process and coming to consensus
on their respective resolutions.


> This project was supposed to discuss moving DMARC from informational to
> standards track.   It has been hijacked by those who, to paraphrase
> Shakespeare, “have not come to praise DMARC, but to bury it.”   This has
> been abetted by the chair’s assertion that we must square a circle – meet
> the MLs requirement for them to impersonate without authorization while
> continuing to advance the DMARC requirement to prohibit impersonation
> without authorization.
> [...]
>
I have not yet seen any assertion that DMARC needs to be buried.  In fact,
revisiting its assumptions is a perfectly feasible way to come to consensus
on its goals and how they might be achieved.  If DMARC was founded on false
premises, that plainly needs to be considered and possibly fixed.  That can
only strengthen it.

None of this discussion seems invalid to me.

As part of that hijacking, we have been inundated by Mr. Crocker’s
> assertions that the message From Address does not matter.  All the years of
> theoretical analysis that preceded DMARC and all of the operational success
> from implementations of DMARC are just wrong, simply because he says so.
>
It's not simply because he says so.  At the time DMARC was on the drawing
board, the MUA game was different.  We talked about this a lot back then,
and it was discussed previously in this working group too.  These days,
there's evidence to suggest that the domain name is rarely visible.  If
that's true, I claim it's a valid thing to revisit whether DMARC as it's
currently designed is providing useful protection especially with respect
to the disruption it causes elsewhere.


> More importantly, this discussion has failed to address the actual
> objective, which is to solve the asserted Mailing List problem as it
> relates to AOL/Yahoo/Verizon.   That enterprise does not seem to be
> involved in this process, and no one has offered reason why they will be
> swayed by anything said here.    The strategy seems to be that if we tell
> these people how stupid they are, that they will do whatever we tell them
> they must do, even if the solution is to weaken security for everyone on
> the Internet.    That is not a winning strategy.
>
I think this is all a little hyperbolic and not especially constructive.

RFC 7489 was co-edited by a Yahoo engineer.  I'm pretty sure she's paying
attention, either here or in related industry trade groups.  The others are
probably at least being made aware of it via the latter.

The IETF is not the protocol police.  If you need evidence of this, simply
note that RFC 7489 was deployed despite who participated in its development
and how many consensus documents warned against its use in mail flows where
Mediators are present.

DMARC has been mandated by at least three national governments,, by a
> variety of businesses, and by this one consumer-oriented email hosting
> service.   It is here to stay, and any extensions to the specification will
> need to improve security, not weaken it for the benefit of a special
> interest group.
>
This sounds a lot like an argument from authority.

There is no doubt that anti-phishing technologies are critical, and it's no
surprise that a protocol characterized as effective against phishing is
being widely endorsed.  The question being proposed here is whether DMARC
actually still fits that bill given the current state of the industry.  I
suggest that this is a perfectly valid question, and I would really like
you to explain why it should be declared moot or off-topic.

Instead, we should be anticipating that the U.S. government will begin
> mandating DMARC for its contractors, in phases based on contractor
> categories.    Simply requiring it for Department of Defense contractors
> would be sufficient to include most of the major research-oriented
> universities.   But every school that takes student loan payments is also
> considered a government contractor, which covers almost all of them.
>  Every branch of state and local government also feeds from the federal
> trough, and concerns about election meddling means that they are likely
> targets for voluntary or required implementation of DMARC.   Essentially
> every health care institution is also a government contractor, because they
> take payments from Medicare or Medicaid, usually both.
>
Yes.  Wouldn't it be an atrocity if they bolted their security stories to a
lemon?

It is time to begin a discussion rooted in what is feasible, and what is
> appropriate for IETF to undertake.
>

There, we agree.

-MSK