[dmarc-ietf] Protocols All The Way Down (long - sorry)
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
Re: [dmarc-ietf] Another p=reject text proposal
On Mon 10/Jul/2023 17:50:54 +0200 John Levine wrote: FYI, the IETF's mail relay for role accounts like WG chairs breaks DKIM signatures. It's a bug, but it took quite a while to realize what the problem was, since some signatures get through OK. It's an old python library helpfully tidying up the message headers. Fixing the bug is nontrivial due to the cruftiness of the surrounding code. See tools-discuss for way more details. In theory relays shouldn't break DKIM, in practice ... Let me note, tangentially, that that may also look like a DKIM over-signing issue. My tool[*] didn't verify the original signatures of the message I'm replying to because Content-Type: was changed to «text/plain; charset="utf-8"», where it likely was «text/plain; charset="us-ascii"». We can consider the bug to be in the helpfully tidying up, in the over-signing practice, or somewhere in between. Best Ale -- [*] https://mailarchive.ietf.org/arch/msg/dmarc/wFTm0dfCdWso5c7uJz4Or8XBoZU/ ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
> Another consideration is that a non-standard, internal blocking would have > been > effective only for their users. Perhaps they though they were doing the rest > of the world a favor by following standard protocols. Had that MUST NOT been > in place then, /perhaps/ we'd have spared ourselves lots of fuss and p=reject > would have remained a seldom deployed feature. To be clear, I don't think "seldom deployed" is right: I think there's a lot of valid and intended use for p=reject... just not for a global mailbox provider and domains like it. > +1, when we'll learn to use ARC we can stop From: munging. Will we then > retract that MUST NOT (and DMARCbis with it)? The intent, and I think it's hinted at in the text I proposed, is that when things get to where these interoperability issues are adequately mitigated and the requirements put forth in the Interoperability Consideration section should change, we would publish an RFC that "updates" this one and specifies the new requirements (or rescinds them entirely) as appropriate. Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
It appears that Barry Leiba said: >> Is “generally” true here? I think I have seen exceptions to DKIM signatures >> being valid on relayed >> messages, although I can’t dig up any examples right now. > >You seem to be answering the question you're asking. I know of none >of these relays that break DKIM signatures, but we hear that some do. FYI, the IETF's mail relay for role accounts like WG chairs breaks DKIM signatures. It's a bug, but it took quite a while to realize what the problem was, since some signatures get through OK. It's an old python library helpfully tidying up the message headers. Fixing the bug is nontrivial due to the cruftiness of the surrounding code. See tools-discuss for way more details. In theory relays shouldn't break DKIM, in practice ... R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Sat 08/Jul/2023 20:13:44 +0200 John Levine wrote: It appears that Richard Clayton said: They then moved on to just using random identities from the same domain as the recipient. This led a great many Yahoo users to believe that a great many other Yahoo users had been compromised, leading to a significant loss of faith in the integrity of the platform. We get that, but why did they have to inflict DMARC policy on the world rather than just adjusting their own mail software to filter out incoming mail with Yahoo return addresses from other places? I assume the answer was that the DMARC code was already written so it was cheaper. Another consideration is that a non-standard, internal blocking would have been effective only for their users. Perhaps they though they were doing the rest of the world a favor by following standard protocols. Had that MUST NOT been in place then, /perhaps/ we'd have spared ourselves lots of fuss and p=reject would have remained a seldom deployed feature. strong, mailing lists (and other forwarders that mangle email) have been coping with p=reject for nearly a decade -- so that trying (ineffectually in practice) to make their lives easier at this point is a snare and a delusion. There seem to be a fair number of people working on ARC who disagree. +1, when we'll learn to use ARC we can stop From: munging. Will we then retract that MUST NOT (and DMARCbis with it)? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
> I’m one of those people who prefer for “xxx considerations” sections to be a
> descriptive discussion
> of the xxx issues and not contain new normative requirements.
I disagree, and certainly the Security Considerations sections are
normative and often use BCP 14 key words.
> the statement above sounds a little like the normative language is moving
> because it only addresses
> an interoperability issue.
It's moving in order to (1) put the requirements for senders and
recipients in one place in order to make the reasoning clear and (2)
to allow a broader discussion of the issues and the reasons without
cluttering the sections that lay out the protocol. I think it's
important to put the requirements and the reasons for those
requirements in the same place: its clearer to readers and it
emphasizes the needs for the requirements.
> [Is there a significance to the indentation of the 3rd, 6th, and 8th
> paragraphs below?]
It calls out the requirements clearly. The rest of the text explains
why, and the indented text contains the requirements concisely.
> >not an address authorized for the sending domain. DKIM signatures
> >will generally remain valid in these relay situations.
>
> Is “generally” true here? I think I have seen exceptions to DKIM signatures
> being valid on relayed
> messages, although I can’t dig up any examples right now.
You seem to be answering the question you're asking. I know of none
of these relays that break DKIM signatures, but we hear that some do.
So, "generally" means it's not wrong. I'm happy to use a different
word or phrase if you suggest one.
> > It is therefore critical that domains that host users who might
> > post messages to mailing lists SHOULD NOT publish p=reject.
> > Domains that choose to publish p=reject SHOULD implement
> > policies that their users not post to Internet mailing lists.
>
> A few paragraphs earlier discussed “alumni” and role-based addresses. But now
> it sounds like only
> mailing lists are important. It would seem that domains that send messages to
> alumni and role-based
> addresses also SHOULD NOT publish p=reject. But there’s no way for those
> domains to know when
> they’re sending to such addresses.
The relaying for alumni and roles will ("generally", as noted)
maintain DKIM authentication, which mitigates the issue for those
types, and we already put the MUST requirement of not using SPF alone
with p=reject. So this requirement need only be for mailing lists, as
they're the cases that (again, generally) break DKIM signatures.
> I agree with Murray’s comment: a SHOULD NOT like this need to cite what the
> exceptions are.
> “Our domain is very worried about domain spoofing” and the like don’t seem
> like a suitable
> exceptions to me.
I think the explanatory text makes the situation abundantly clear,
without the need for further clarification here. As I've said, I
prefer MUST NOT here, but it's clear to me that we will not get rough
consensus on that, and SHOULD NOT will still cover the situation
reasonably. And, like it or not, "we're worried about spoofing" *will
be* the reason this is ignored. Do you (or Murray) really want to say
that explicitly? I certainly don't.
> > It is therefore critical that receiving domains MUST NOT reject
> > incoming messages solely on the basis of a p=reject policy by
> > the sending domain. Receiving domains must use the DMARC
> > policy as part of their disposition decision, along with other
> > knowledge and analysis.
>
> Isn’t this basically just factoring address alignment along with DKIM and SPF
> pass into spam filters?
> I’m pretty sure spamassassin already does that, even without DMARC.
Not just that, no. Receiving domains might consider various
allow-lists, contents of recipients' address books, message content
filtering, knowledge of common mailing list managers, and other such
factors.
Barry
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC session agenda for IETF 117
List links added. Barry On Sun, Jul 9, 2023 at 2:15 PM Jim Fenton wrote: > > Barry, > > Can you add pointers to the various text options (perhaps links to the > mailing list archive) so we’re all working off the same text? And which is > the “current text”? > > -Jim > > On 6 Jul 2023, at 8:00, Barry Leiba wrote: > > > Below is the agenda I am posting for the session at IETF 117. > > Comments, changes, and additions are welcome; please post them here. > > > > Barry > > > > --- > > > > DMARC working group session at IETF 117 > > Friday, 28 July, 2023 — 12:00-13:30 PDT (UTC-7) > > > > - Introduction and administration > > - Document status > > > > - Discussion of p=reject: > > - What’s needed to deal with the indirect mail flow problems? > > - Options currently open: > > - No change to current text > > - Move ARC to Standards Track (need more data) > > - Scott Kitterman’s proposed text > > - Barry Leiba’s proposed text (new Interoperability Considerations > > section) > > - AD will call consensus on this issue > > > > - Discussion of SPF use in DMARC > > - There was a proposal to remove SPF from DMARC > > - The proposal is *only* related to use of SPF *in DMARC* > > - Options currently open: > > - No change to current text > > - Simply remove SPF from DMARC consideration > > - Add a DMARC record tag to specify use of SPF, DKIM, or either > > - Do we also add “both must align”? > > > > - Any other business > > > > --- > > > > ___ > > 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
