Hi,
each mechanism approaches the problem in a different way:
- SPF authorizes selected hosts (machines approved to send mail)
- DKIM authenticates sender (proof of origin)
- ARC authenticate senders chain (also proof of origin, but also proof
of whole communication chain)
we can also continue with other technologies, but this is not matter the
DMARC story. For example S/MIME and GPG are from my perspective proof of
will.
In a previous communication, I listed SPF as an obsolete technology.
Also, this is matter of my perspective, due to problems in cloud systems
where thousands of domains are on similar machines/address ranges. For
this reason, SPF is currently limited in use, yet it still has its uses.
In a previous communication, I also reported on measurement statistics
about saturation of specific technologies. These statistics are
collected over domains. I will try to figure out the number of that
domains, we did that analysis about one year ago. Total volume are about
50 million e-mails per week. The problem with collecting this data is
distribution across different mail systems on about 7000-8000 domains
and another thousands of subdomains (oscillating in time).
From my point of view, the biggest problem at the moment is the
protection of the sender's brand, i.e. the ability to unambiguously
identify from which source the email originated and whether it was
counterfeit (has been e-mail forged or not?). Current technologies such
as SPF, DKIM and ARC, DMARC try to ensure this protection, but the owner
is limited in deciding how he can allow his authentication. Since he is
dependent on the correct implementation of these technologies by the
recipient, he should be able to define his requirements. He cannot
enforce them, but any problems due to the poor authentication of the
sender then go to the recipient.
Regards
Jan
Dne 12. 7. 2023 v 3:18 Douglas Foster napsal(a):
So we disable SPF when the sender tells us to do so., but leave it enabled
by default That makes a lot of sense to me.
When the domain passes SPF on a shared server farm, but provides no DKIM
signatures, I currently have no choice other than to consider the message
to be authenticated. The AUTH token will provide that reason.
Hosting services could insist that senders configure DKIM, but that seems
to be a pipe dream.
Doug
On Tue, Jul 11, 2023, 8:50 PM Wei Chuang <weihaw=40google....@dmarc.ietf.org>
wrote:
The data we presented June 20th (archive
<https://mailarchive.ietf.org/arch/msg/dmarc/KeGbMfX91WJk_aziKsrRfI6AYkI/>)
also suggests that it is premature to drop SPF from DMARC. However I
differ in believing that we should accept the spoofing risk demonstrated
recently via SPF, and that we shouldn't strive to reduce it by making
improvements to DMARC and possibly SPF. One approach is to enable
different senders to distinguish their differing levels of risk and
infrastructure by letting them specify an "auth=" flag proposed on the
20th
<https://mailarchive.ietf.org/arch/msg/dmarc/KeGbMfX91WJk_aziKsrRfI6AYkI/>.
For example a mom-and-pop sender on their own infrastructure with their own
IPs will have a different profile than a risky, enterprise sender on shared
IPs. The former would be reasonably safe using SPF and would benefit most
from using it. The latter should use DKIM authentication only due to the
risk of SPF upgrade spoofing and the phishing exposure. I describe some
additional ideas about how to use "auth=" flag with different risk and
infrastructure stratification on the DKIM list on July 3rd (archive
<https://mailarchive.ietf.org/arch/msg/ietf-dkim/6ms55apP0RtLzr34CCgjWRYkVsA/>
).
And FWIW I don't think mom-and-pop senders will find it that hard to adopt
DKIM if sufficiently motivated. For example for BIMI on Gmail, we now
require DKIM-only authentication. Indeed a new BIMI sender that I perceive
to be running literally a "mom-and-pop" produce shop was using SPF
authentication and was confused as to why their logo wasn't showing. After
explaining the requirement they were able to move to DKIM authentication in
one day. Yes, it did take explaining twice what was happening, but they
were able to deploy DKIM on their own and got their logo to show up.
Also can we do more to harden SPF? The SPF upgrade attacks needs three
things:
- IPs shared by multiple sending domains
- Some sender uses those IPs that permits spam and phish traffic
- Those multiple sending domains have SPF policies that include those
IPs
Perhaps one way to harden to SPF for DMARC is to detect if the IPs are
shared. The authenticator in addition to regular to SPF validation, might
be able to use reverse PTR lookup and match the SPF record domain name (or
match some subset like the org domain) to forward validate. Only one
domain can claim ownership for the IPs and be allowed to SPF authenticate
for DMARC.
-Wei
On Mon, Jul 10, 2023 at 5:38 PM Scott Kitterman <skl...@kitterman.com>
wrote:
I've been thinking about the thread on ditching SPF relative to DMARC.
DMARC is built on other protocols. Piles of them.
DMARC is built most directly on DNS, DKIM, and SPF. It is also built on
SMTP
and Email. DKIM and SPF are also built on DNS and SMTP (SPF) or Email
(DKIM).
These protocols are built on others. All of them have flaws and
limitations.
As an example, although each of the three top level protocols in this
particular stack depend on data from DNS being reliable, they merely
counsel
caution about DNS spoofing, they don't mandate DNSSEC. Note that other
protocols have different choices in this regard (e.g. DANE).
We accept the risk of DNS spoofing associated with non-DNSSEC secured DNS
because the view is that the benefit to deployability of SPF, DKIM, and
DMARC
is sufficient to offset the risks.
What are the risks? Since DNS spoofing is not particularly easy since
Dan
Kaminsky got everyone to implement source port randomization [1]. I
think
it's reasonable to assume if an actor is going to the trouble to spoff
SPF/
DKIM/DMARC records, then it's to try and get a 'bad' message to appear
authentic. I'm not aware of this being a significant problem (probably
since
there are easier ways to do it), so I think the design decision to not
limit
these protols to DNSSEC protected domains is a reasonable one.
Similarly, SPF pass results can be leveraged to a DMARC a DMARC pass
result if
an actor can manage to get a third party provider to accept mail to be
sent
with the victim domain's mail from when that domain has listed that third
party as a source of authorized mail. RFC 7208 warns about this risk {2}.
DKIM has different risks. The cryptographic mechanism used by DKIM is
meant to
provide strong, but limited duration assurance that an email was sent
through
a mail server authorized to do so and additionally that it has not been
modified in certain ways since. This has not always worked out well
[3]. It
only took the IETF six years to address the issue [4]. Additionally, for
some
types of senders, they can be vulnerable to replay if they sign on 'bad'
message in error. This is an issue that was identified during DKIM's
development and warned about in the protocol documentation [5].
This might all seem terrible, but it's really not. If you look that the
goals
of DMARC (current draft section 2.1), they are modest. Specific to this
particular question:
* Allow Domain Owners and PSOs to assert their desired message
handling for authentication failures for messages purporting to
have authorship within the domain.
* Reduce the amount of successfully delivered spoofed emails.
The risks associated with all the above issues are that there are cases
where
'bad' messages pass DMARC and so the domain owner/PSO policy is not
applied.
Given that none of these protocols are perfect (and the risks extend much
further than these I've highlighted), there are always going to be
messages
that get marked DMARC pass that are 'bad'. Fundamentally 'good' and
'bad'
aren't fully reducible to a protocol and the gaps between the protocol
and
human judgement will always exist.
Any message that passes DMARC should still be sugject to the normal spam/
phising prevent processing done by receivers. Just because you got an
email
from bigbank.example which passed DMARC, doesn't mean that it might not
have
been sent through a compromised desktop in bigbank.example's office that
has the
least professionally run information secuirty opreation.
DMARC is going to have false positives and false negatives and those need
to
be considered by implementers when assessing how to use DMARC. The
'problem'
with DMARC (including the 'problem' with SPF in DMARC) only arises when
DMARC
results are used in ways that were never intended. By design and based
on the
goals of DMARC, a DMARC pass result doesn't carry any guarantee that any
particular email was in fact sent legitimately by the organization that
claimed to send it, but unfortunately, people are assuming it does [6].
As I've said before, I don't think dropping SPF from DMARC is a good idea
and
I don't think it will usefully solve the problem that proponents of
dropping
think it will solve. I do think we need to do something in the draft to
address the overall question of the reliability of the DMARC assertion
that a
particular message is authorized/has been authenticated.
The think that the current security considerations are insufficient and
we can
address these concerns by expanding on them. Currently, the DMARCbis
Security
Considerations start with:
11.1. Authentication Methods
Security considerations from the authentication methods used by DMARC
are incorporated here by reference.
I would assess that as necessary, but not sufficient. Here's my proposal
for
expanding 11.1:
11.1. Authentication Methods
Security considerations from the authentication methods used by DMARC
are incorporated here by reference. See [RFC6376 Section 8] and [RFC
7208,
Section 11]. Failures in the underlying methods can result in
incorrect
DMARC results. The impact of such incorrect results is that sender's
DMARC
policy would not be applied in some cases where that is desirable.
Since
DMARC itself associates no positive attribute with a DMARC pass
result, the
impact of these cases is generally minor. Any domain owner that
intends to
make use of positive DMARC results as an overall indication of domain
reputation will need to carefully assess the impacts of these risks to
such
an assertion.
Something like that. I think this topic should be on the meeting agenda
too.
Scott K
[1] https://lwn.net/Articles/289138/
[2] https://datatracker.ietf.org/doc/html/rfc7208#section-11.4
[3] https://www.wired.com/2012/10/dkim-vulnerability-widespread/
[4] https://datatracker.ietf.org/doc/html/rfc8301
[5] https://datatracker.ietf.org/doc/html/rfc6376#section-8.6
[6]
https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
