Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Wei Chuang]

I don't think the SPF '?' qualifier approach works because as Richard
Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1" section 8.2 which says:

A "neutral" result MUST be treated exactly like the "none"  result;
the distinction exists only for informational purposes.

If it happens to work, it's likely an implementation detail not
standardized across the ecosystem and may change.  Moreover it will be
highly confusing to those outside of those with connection to the
knowledgeable few.  That broader community depends on the literal
interpretation of the RFC.
-Wei

On Sat, Oct 28, 2023 at 3:58 PM Mark Alley  wrote:

> For the shared provider SPF upgrade example, I think Scott's previously
> mentioned method of using SPF '?' qualifier on the relevant shared
> mechanism mitigates the upgrade problem, and ensures only DKIM can provide
> passing authentication.
>
> Thinking back earlier this year to the well-publicized SPF upgrade
> vulnerability of a certain vendor, many affected senders mitigated it until
> fixed by the vendor by utilizing the aforementioned neutral ? qualifier
> method to great effect.
>
> Do we really need this when existing protocol methods of mitigating SPF
> upgrades already exist?
>
> This is basically like painting a potato red, and calling it a tomato. It
> still tastes like a potato.
>
> -Mark Alley
>
> On Sat, Oct 28, 2023, 3:04 PM Emanuel Schorsch  40google@dmarc.ietf.org> wrote:
>
>> As to why, I don't think there's a valid use case and the proponents for
>>> this haven't really thought it through.  As an example, someone (I don't
>>> recall who) cited the issue of domain owners that publish SPF, but can't be
>>> bothered to set up DKIM.  The implication is that this minimum effort
>>> domain owner will read DMARCbis when it comes out and decide to update
>>> their records as a result with the new tag.  I don't think that's very
>>> realistic.
>>>
>>> So who would use this tag then?
>>>
>>> It would have to be a domain owner which publishes an SPF record that
>>> enables spoofing their domain, understands SPF and DMARC well enough to
>>> know that is a concern for DMARC and yet simultaneously doesn't know how to
>>> fix their SPF record and does know about this new tag.
>>>
>>> I don't think that person exists.  At best this new tag is some kind of
>>> security theater.
>>>
>>
>> Thanks for that clarification! I think I can clear up what the specific
>> use case is. It's to deal with SPF Upgrade. Assume we have a domain, `
>> business.com`, that has properly set up SPF and DKIM and uses a shared
>> provider and so includes the relevant provider IPs in their SPF record.
>> They have a DMARC p=reject policy. But, unfortunately, the shared provider
>> they use is vulnerable to SPF upgrade and so there have been successful
>> upgrades allowing a spammer / phisher to achieve a `business.com` SPF
>> pass. Notably, this does not allow the spammer to achieve a `business.com`
>> DKIM pass. Today, this will be a DMARC pass (because of the SPF), and it is
>> not always so easy for downstream receivers to know there has been an
>> upgrade.
>>
>> Take the above example, and imagine we've added an `auth=dkim` tag
>> option. `business.com` then adds it to their DMARC record to protect
>> their domain. Now, when a receiver gets the upgraded message they see it is
>> a DMARC fail and can reject the message. This protects the `business.com`
>> domain from impersonation in a way that is not possible today without `
>> business.com` either removing SPF or leaving their shared provider (the
>> only ways to "fix their SPF record"), both a much larger change. Does that
>> make more sense as a legitimate use case?
>> ___
>> 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

Re: [dmarc-ietf] DMARC session at IETF 118

[Wei Chuang]

I'd vote for discussing the "auth=" tag proposal at IETF-118, and I can
participate remotely.  Discussing this on the mailing list is easier, but
will be drawn out as it's harder to understand if there is consensus one
way or the other.  The advantage is that this will time box the discussion
and I've heard many voices wanting closure so that DMARCbis can be
published.
-Wei

On Sat, Oct 28, 2023 at 11:02 AM Scott Kitterman 
wrote:

>
>
> On October 28, 2023 5:38:00 PM UTC, Barry Leiba 
> wrote:
> >I'm starting this in a separate thread that I want to keep for ONLY
> >the following question:
> >
> >Do we want to use the session we have scheduled at IETF 118 to talk
> >about the issue that clearly is still in discussion about adding a tag
> >to specify which authentication mechanism(s) to use when evaluating
> >DMARC?
> >
> >Or shall I cancel the 118 session and just let the discussion continue
> >on the mailing list?
> >
> >And being clear here: the "eliminate SPF entirely" suggestion is
> >definitely out, failing rough consensus.  We're *only* talking about
> >the suggestion to add a tag to specify what the sender wants.
> >
> I think cancel the meeting and keep the discussion on the ML.
>
> Scott K
>
> ___
> 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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Wei Chuang]

I  concur with what Doug mentioned.  As someone on the receiving end of bad
press due to an exploit of what I perceive to be weaknesses in the DMARC
standards particularly around depending on SPF [1], and then had to drop
everything to mitigate, I would suggest taking this opportunity to
strengthen DMARCbis.  After all, preventing From header spoofing is the
core of what DMARC is about.  As for why a new tag, I noted in [2], we see
a high degree of overlapping coverage in DKIM and SPF authentication, but
there is a small set of SPF only authentication that likely needs coverage,
and noted that different senders have different From header security needs
e.g. those that use cloud services really should only use DKIM but a very
small sender might not.  As noted, I proposed language [3] for DMARC to
enable this change, and at least on that thread there seemed to be
consensus.
-Wei

[1] There was an attack on BIMI starting on March 31.  An attacker was able
to exploit a large cloud provider that provides mail services for many well
known companies to forward a message with a spoofed From header.   That
message could obtain SPF authentication using the relay's IP SPF, thereby
getting a DMARC pass hence a BIMI pass.  Agreed with the earlier statement
that the fault here doesn't appear to lie with SPF domain owner as they
appeared to have followed reasonable practices.  Rather SPF relies upon IP
which is very often shared between multiple senders.  The Forward Pass
paper documents this very well:
https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf
[2] https://mailarchive.ietf.org/arch/msg/dmarc/KeGbMfX91WJk_aziKsrRfI6AYkI/
I realized that the archived text version of tables there got munged, so
putting the key table back to format for text:
The following categorizes combination of SPF and DKIM authentication of
percentage of traffic that Gmail sees on a given day.  Of this traffic,
DKIM is not passing for 5.56% and of that there's SPF coverage for 4.78%
(86% of DKIM not passing).  A large cause for this is messages that were
not DKIM signed but could be validated with SPF at 3.91% (70% of DKIM not
passing).

ConcatSpfPassDkimAuthResults %
TRUE,PASS92.58%
TRUE,NEUTRAL 3.91%
FALSE,PASS   1.85%
FALSE,NEUTRAL0.72%
TRUE,FAIL0.69%
TRUE,TEMPERROR   0.17%
FALSE,FAIL   0.05%
FALSE,TEMPERROR  0.02%
TRUE,POLICY  0.00%
FALSE,POLICY 0.00%
Grand Total100.00%

[3] Initial "auth" tag proposal
https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/
and with comments rolled up
https://mailarchive.ietf.org/arch/msg/dmarc/oqcJoGfBCX0C3Y7yZzCga3k6sTs/

On Thu, Oct 26, 2023 at 5:27 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Like Ale, I thought the group had agreed to implement an auth=DKIM-only
> option of some type.
>
> I understood the motivation to be false pass created by malicious
> forwarding through a legitimate hosting platform.  Therefore  SPF precision
> is an unrelated issue.
>
> Doug
>
> On Thu, Oct 26, 2023, 5:46 PM Tero Kivinen  wrote:
>
>> John Levine writes:
>> > It appears that Scott Kitterman   said:
>> > >>* Is there consensus on moving ahead with the idea of a way to
>> indicate
>> > >>which authentication method(s) the Domain Owner wants Receivers to
>> use?  If
>> > >>so, it doesn't seem to be in the document yet.
>> > >
>> > >I haven't seen any valid case for it yet.  It adds complexity to
>> > >little or no benefit.
>> >
>> > Normally I am in favor of keeping stuff simple, but I think in this
>> case the
>> > argument for "DKIM only" is quite strong.
>>
>> Actually removing SPF completely from DMARC would simplyfy the
>> protocol a lot, and would solve several issues, where people use DMARC
>> with only SPF, or claim to do dmarc, but do filtering based on the SPF
>> records before getting to the actual email, thus not checking DKIM
>> records at all.
>>
>> If the DMARC would only use DKIM, that would make it clear that if you
>> want to publish DMARC records you needs to also use DKIM, and when
>> checking DMARC records you need to check verify DKIM signatures.
>>
>> Whether you do SPF in addition to that before or after would be local
>> implementation issue, and not part of the DMARC.
>>
>> There were people who wanted to keep SPF as part of the DMARC, who did
>> not even do DMARC, because the used SPF only as a first step of
>> filtering during the MAIL FROM phase (before being able to fetch DMARC
>> records, or checking DKIM signatures)...
>>
>> > There's the counterargument "so don't publish SPF" but it's on so
>> > many checklists that even though that would be a fine idea, it's not
>> > practical.
>>
>> That is unfortunately true, but if we could decouple the DMARC from
>> SPF, then at least we could fix the situation at some point

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Wei Chuang]

On Sun, Sep 10, 2023 at 11:34 AM Scott Kitterman 
wrote:

> On Thursday, September 7, 2023 12:28:59 PM EDT Wei Chuang wrote:
> > We had an opportunity to further review the DMARCbis changes more broadly
> > within Gmail.  While we don't see any blockers in the language in
> DMARCbis
> > version 28
> > <https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-28> and
> > can live with what is there, we wanted to briefly raise some concerns
> > around some of the changes.  Two points.
> >
> > Regarding the languages in section 8.6 "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", we wanted
> to
> > point out that this is impossible to implement.  Many enterprises already
> > have "p=reject" policies.  Presumably those domains were subject to some
> > sort of spoofing which is why they went to such a strict policy.  It
> would
> > be unreasonable to tell them to stop posting to mailing lists as many
> > likely already use mailing list services and will want to continue to use
> > them.  The one thing that makes this tractable is the SHOULD language as
> we
> > may choose not to not follow this aspect of the specification.  Our
> > suggestion is that there is not a lot of value in including this language
> > in the bis document if the likely outcome is that it will be ignored, and
> > rather more effort should be placed with a technical solution for interop
> > with mailing lists.
>
> It might be helpful if you could describe this technical solution from
> your
> perspective.
>
> If there were a reasonable technical solution available, I think this
> would be
> a much easier change to support (in my opinion, and a believe a
> substantial
> number of others, rewriting From is not a reasonable technical solution).
>
> Scott K
>

Apologies for the delay in getting back to this.

So yes I believe there are two possible technical approaches broadly
speaking 1) Support rewriting From and being able to reverse it along with
message modifications to recover the original DKIM message hash to validate
the original DKIM signature.  2) Create a new message authentication method
that is tolerant of message modifications and message forwarding, and
supported by DMARC.  From header rewriting would not be necessary in this
scenario.  Beyond the complexity of supporting either method, another
tricky thing in both cases is supporting an ecosystem with diverse adoption
of said technique.  More concrete proposals for 1) and 2) are 1)
draft-chuang-mailing-list-modifications
<https://datatracker.ietf.org/doc/draft-chuang-mailing-list-modifications/> and
2) draft-chuang-replay-resistant-arc.  And there are other I-Ds out there
particularly for the first approach.

-Wei
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Wei Chuang]

We had an opportunity to further review the DMARCbis changes more broadly
within Gmail.  While we don't see any blockers in the language in DMARCbis
version 28
 and
can live with what is there, we wanted to briefly raise some concerns
around some of the changes.  Two points.

Regarding the languages in section 8.6 "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", we wanted to
point out that this is impossible to implement.  Many enterprises already
have "p=reject" policies.  Presumably those domains were subject to some
sort of spoofing which is why they went to such a strict policy.  It would
be unreasonable to tell them to stop posting to mailing lists as many
likely already use mailing list services and will want to continue to use
them.  The one thing that makes this tractable is the SHOULD language as we
may choose not to not follow this aspect of the specification.  Our
suggestion is that there is not a lot of value in including this language
in the bis document if the likely outcome is that it will be ignored, and
rather more effort should be placed with a technical solution for interop
with mailing lists.

We question the benefit versus the implementation effort and confusion of
deprecating the DMARC policy "pct" percentage mode and replacing it with
"t" test.  We do agree that there is benefit in having receivers support a
debug mode to enable DMARC deployment and that the test mode supports the
most useful use case for testing with indirect mailflow behavior.   However
"pct" represents a sunk cost and implementing test mode seems redundant to
the already existing "pct" percentage mode.  Moreover both modes will
likely need to be supported for a while.  We do see senders use "pct"
ratcheting and it will be confusing to them when at some point they will
have to switch.


-Wei
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

[Wei Chuang]

I've also tried rolling up the comments in this thread as well.  Below is
the result:
-Wei
=

1. Introduction, 3rd paragraph insert after first sentence:

In addition, the choice of permitted authentication methods, SPF or DKIM,
method MAY be explicitly specified, potentially to restrict the supported
authentication methods.

4.3 Authentication Mechanisms append:

Domain Owners and PSOs MAY explicitly specify the supported authentication
methods via the OPTIONAL auth tag.  The value is a colon ':' separated list
of supported authentication methods.  The order of the list is not
significant,  and unknown methods are ignored. An aligned passing result
for any listed method indicates a DMARC pass.  An empty list of methods is
a syntax error.  If auth is unspecified, the default is "spf:dkim" and both
DKIM and SPF authentication methods are supported.

5.3 General Record Format insert:

auth:  (colon-separated plain-text list of dmarc-methods; OPTIONAL; default
is "spf:dkim")
Indicates the supported authentication methods.  The order of the list
is not significant and
unknown methods are ignored.  Possible values are as follows:
dkim: Authenticate with DKIM
spf: Authenticate with SPF

An empty list of methods is a syntax error.

If any listed method passes and is aligned, then DMARC passes.


5.4. Formal Definition insert:

dmarc-method = "dkim" / "spf"

dmarc-auth = dmarc-method *(*WSP ":" *WSP dmarc-method)



Tag Name
Value Rule
auth.  dmarc-auth


On Mon, Aug 7, 2023 at 2:30 PM Murray S. Kucherawy 
wrote:

> Fine with me, just wanted to ask the question.
>
> -MSK, hatless
>
> On Mon, Aug 7, 2023 at 1:48 PM Barry Leiba 
> wrote:
>
>> Indeed.  We can do what we've done in other cases: create a registry
>> if/when we add something else later.
>>
>> Barry
>>
>> On Mon, Aug 7, 2023 at 4:11 PM Scott Kitterman 
>> wrote:
>> >
>> >
>> >
>> > On August 7, 2023 7:47:03 PM UTC, "Murray S. Kucherawy" <
>> superu...@gmail.com> wrote:
>> > >On Sat, Aug 5, 2023 at 1:09 PM Tim Wicinski 
>> wrote:
>> > >
>> > >> Based on the ABNF in -28, how about something like this:
>> > >>
>> > >>
>> > >> dmarc-method = "dkim" / "spf"
>> > >>
>> > >> dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method)
>> > >>
>> > >>
>> > >> I think this "should"(*)  allow for all permutations but also
>> simplifies
>> > >> it, and I agree with Barry it should be simpler.
>> > >>
>> > >
>> > >This looks good to me, except to be consistent with DKIM (from which
>> this
>> > >general syntax was borrowed) I'd suggest:
>> > >
>> > >* using colon as the separator rather than comma
>> > >* WSP and CFWS should follow whatever we did for other tags
>> > >* don't allow an empty list; I can't think of any DKIM or DMARC tag
>> that
>> > >accepts a list and also allows an empty value
>> > >
>> > >If we think we might add "arc" or something else in the future, do we
>> need
>> > >a registry of supported methods?  If not, we'll have to rev DMARC every
>> > >time a new one comes into favor.
>> >
>> > I think we don't need a registry.  Rationale:
>> >
>> > 1.  There is no additional method that's being contemplated (whatever
>> ARC is, it's not a first class alternative to SPF or DKIM).
>> >
>> > 2.  Currently, we have text in the specification to describe how to use
>> the output of SPF and DKIM for DMARC.  I don't think there's much prospect
>> any new method wouldn't need something similar.
>> >
>> > I think a registry would only complicate things and wouldn't actually
>> be helpful.
>> >
>> > Scott K
>> >
>> > ___
>> > 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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposal for additional Security Considerations for SPF Upgrade in draft-ietf-dmarc-dmarcbis

[Wei Chuang]

I've tried to roll up the guidance in this thread in the results below.
-Wei

=

11.9 Quarantined Forwarded Mail Security Risk

When receivers apply the "MUST NOT reject" in Section 8.6 to accept
unauthenticated messages as quarantined messages, receivers ought to
carefully review how they forward mail traffic to prevent additional
security risk.  The forwarded mail might be able to obtain SPF or DKIM
authentication through the receiver, and thereby obtain a fraudulent DMARC
aligned From despite having an associated strong DMARC policy of
"p=reject".  For SPF, a malicious sender needs two properties to perform
such a SPF attack: 1) a receiver that will forward quarantined messages,
and 2) the spammer finds a SPF policy that covers the forwarding IPs.  Such
a sender crafts a message with From header assuming the identity of the
domain with the SPF policy and matching MAIL FROM.  Consequently the
receiver evaluates message authentication and finds that the MAIL FROM does
not authenticate but does not reject the message and instead quarantines
it.  Vulnerable receivers then forward the message to some subsequent
receiver with the message taking the authenticated identity of the From
header.  That forwarding might be under control of the malicious sender
perhaps via auto-forwarding or enterprise policy.  Receivers need to
consider restricting forwarding when the message is SPF unauthenticated.
For DKIM, a malicious sender finds a forwarder that re-signs messages with
DKIM that lets some malicious email take the identity of the DKIM signer
domain.  Some forwarders appear to do this for all messages.  Other
forwarders might do this when the message is modified such as
mailing-lists.  As with the SPF attack, the malicious sender may be able to
create a message with some From header corresponding to the spoofed
re-signing domain to obtain DMARC alignment at the receiver.  Forwarders
that re-sign messages with DKIM ought to consider the reputational and
identity risk that it imposes.  With ARC [RFC8617], receivers sometimes
override their local DMARC results with results found from the
ARC-Authentication-Result header to prevent mail from being rejected or
quarantined. Malicious senders may target these receivers if that override
is done improperly.  Hence receivers ought to carefully consider whether
they can trust the results passed in the ARC-Authentication-Results as they
are provided by the forwarder without any guarantee they are correct.  SPF,
DKIM and ARC forwarding attacks and other considerations are discussed
further in Liu et. al. [1].

[1] Liu, Enze et al. "Forward Pass: On the Security Implications of Email
Forwarding Mechanism and Policy", Proceedings of the 8th IEEE European
Symposium on Security and Privacy, 2023.

On Sun, Aug 6, 2023 at 1:46 PM Scott Kitterman  wrote:

> That reads to me as guidance for DMARC implementers on how to integrate
> SPF and DKIM  results for the purposes of DMARC.  I think that's in scope
> for DMARCbis.
>
> There's a multitude of ways people can screw these things up and we won't
> be able to cover them all.  The guidance needs to be somewhat high level.
>
> One of my favorites is a case I was asked to investigate where an ESP had
> transmitted a clearly forged email for one of their customers and the
> customer wanted to know why DMARC hadn't protected them, even though they
> had a p=reject policy.
>
> What happened was that the ESP received a DMARC fail email from an
> unrelated mail server that also had a valid ARC signature, so instead of
> rejecting the message, they allowed the ARC result to override the DMARC
> policy and accepted it. Then they relayed it to the final destination
> (which in the same domain as the From domain - which was owned by their
> customer).  There's all kinds of things people can do to mess this up.  I
> don't think it's obscure that one should only believe ARC results from
> trusted sources, but there we were.
>
> Scott K
>
> On August 6, 2023 8:07:31 PM UTC, Wei Chuang  40google@dmarc.ietf.org> wrote:
> >I don't think having this language is saying you can't do SPF.  Rather
> this
> >is about preventing new spoofing attacks on DMARC aligned identity.  In
> >particular where previously this attack was not possible on forwarders
> that
> >honored the p=reject policy, now that they will downgrade to quarantine,
> it
> >opens a new vector that should be reviewed to prevent this attack. I
> >propose this because I've seen the forwarding attack with SPF on ups.com.
> >The Liu et. al. paper notes that they were able to spoof the From header
> >government e.g. state.gov, financial and legal companies with SPF.  You
> >noted that it's feasible with DKIM too.  The RFC should ask forwarders to
> >do this re

Re: [dmarc-ietf] Proposal for additional Security Considerations for SPF Upgrade in draft-ietf-dmarc-dmarcbis

[Wei Chuang]

I don't think having this language is saying you can't do SPF.  Rather this
is about preventing new spoofing attacks on DMARC aligned identity.  In
particular where previously this attack was not possible on forwarders that
honored the p=reject policy, now that they will downgrade to quarantine, it
opens a new vector that should be reviewed to prevent this attack. I
propose this because I've seen the forwarding attack with SPF on ups.com.
The Liu et. al. paper notes that they were able to spoof the From header
government e.g. state.gov, financial and legal companies with SPF.  You
noted that it's feasible with DKIM too.  The RFC should ask forwarders to
do this review when they p=reject downgrade otherwise it does add systemic
risk to the DMARC protected From identity.

-Wei

On Sun, Aug 6, 2023 at 11:38 AM Scott Kitterman 
wrote:

> On Sunday, August 6, 2023 2:10:35 PM EDT Hector Santos wrote:
> > > On Aug 5, 2023, at 5:37 PM, Scott Kitterman 
> wrote:
> > >
> > > On Saturday, August 5, 2023 3:59:02 PM EDT John Levine wrote:
> > >> It appears that Scott Kitterman   said:
> >  When receivers apply the "MUST NOT reject" in Section 8.6 to accept
> >  unauthenticated messages as quarantined messages, receivers SHOULD
> >  carefully review how they forward mail traffic to prevent additional
> >  security risk.  That is, this downgrade can enable spoofed messages
> >  that
> >  are SPF DMARC authenticated with a fraudulent From identity despite
> >  having
> >  an associated strong DMARC policy of "p=reject". ...
> > >>
> > >> We all realize that SPF has problems, but I really do not want to fill
> > >> up the DMARC document with text that says "you can authenticate with
> > >> SPF, hahaha no just kidding."
> > >>
> > >> The way to fix Microsoft's forwarding SPF problem is for Microsoft to
> put
> > >> the forwarding user's bounce address on the message, not for us to
> tell
> > >> the entire world to use kludgy workarounds.
> > >
> > > I agree.  We need to be careful to solve protocol problems in the
> protocol
> > > and leave fixing implementation problems to implementers.  We aren't
> > > going to protocol our way out of bad implementation decisions.
> >
> > Taken within the good-intention, protocol-compliant implementations,
> which
> > one do we add as “Implementations Notes?”  Which or rather What are
> > “Current Practice”behavior can we note?
>
> I think best current practice goes in a different document.  Maybe we do
> that
> after DMARCbis is buttoned up?
>
> Scott K
>
>
> ___
> 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

Re: [dmarc-ietf] Proposal for additional Security Considerations for SPF Upgrade in draft-ietf-dmarc-dmarcbis

[Wei Chuang]

On Sat, Aug 5, 2023 at 1:01 PM John Levine  wrote:

> It appears that Tim Wicinski   said:
> >A malicious sender needs two properties to perform such a SPF upgrade
> >attack:
> >
> >1) a receiver that will forward quarantined messages, and
>
> do so without changing the bounce address.  Solution: Don't Do That.
>

That's a confounding issue but not the root problem I think. Even if
Microsoft were to implement keeping the bounce address, it just means that
the spammer has to start with the spoofed return-path address on their
initial send.  Yes, that fails SPF authentication but it is ignored for
whatever reason and then forwarded.  And it's this forwarding despite the
initial failing authentication that I think is the root of the problem.

Besides, the spammers frequently change tactics.  Just yesterday I saw a
spam message where the return address is empty, though granted it's not
DMARC aligned.


> >> Finally, I don't think this is particularly unique to SPF.  If you
> replace
> >> "finds a SPF policy that covers the forwarding IPs" with something like
> >> finds a third party willing to sign the message, I expect I could
> construct
> >> a similar (if not quite as easy) DKIM based scenario.
>
> No, then it has the forwarding party's signature which isn't aligned with
> the From header.
>

A spammer could write a From header in anticipation of adding a forwarder's
DKIM signature.  This already happens with the SPF upgrade scenario.
-Wei
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposal for additional Security Considerations for SPF Upgrade in draft-ietf-dmarc-dmarcbis

[Wei Chuang]

On Fri, Aug 4, 2023 at 2:11 PM Scott Kitterman  wrote:

>
>
> On August 4, 2023 4:15:35 PM UTC, Wei Chuang  40google@dmarc.ietf.org> wrote:
> >I noted at the DMARC session -117, that with the p=reject downgrade to
> >quarantine language, this increases the risk of SPF upgrade attacks due to
> >forwarding.  The reply was to propose language for this and below is the
> >suggested text for the proposed "11.9 Quarantined Forwarded Mail Security
> >Risk"
> >
> >=
> >
> >11.9 Quarantined Forwarded Mail Security Risk
> >
> >When receivers apply the "MUST NOT reject" in Section 8.6 to accept
> >unauthenticated messages as quarantined messages, receivers SHOULD
> >carefully review how they forward mail traffic to prevent additional
> >security risk.  That is, this downgrade can enable spoofed messages that
> >are SPF DMARC authenticated with a fraudulent From identity despite having
> >an associated strong DMARC policy of "p=reject".  A malicious sender needs
> >two properties to perform such a SPF upgrade attack: 1) a receiver that
> >will forward quarantined messages, and 2) the spammer finds a SPF policy
> >that covers the forwarding IPs.  Such a sender crafts a message with From
> >header assuming the identity of the domain with the SPF policy and
> matching
> >MAIL FROM.  Consequently the receiver evaluates message authentication and
> >finds that the MAIL FROM does not authenticate but does not reject the
> >message and instead quarantines it.  Vulnerable receivers then forward the
> >message to some subsequent receiver with the message taking the
> >authenticated identity of the From header.  That forwarding may be under
> >control of the malicious sender perhaps via auto-forwarding or enterprise
> >policy.  Receivers SHOULD consider restricting forwarding when the message
> >is SPF unauthenticated.  SPF upgrade attack and other considerations are
> >discussed further in Liu et. al. [1].
> >
> >[1] Liu, Enze et al. "Forward Pass: On the Security Implications of Email
> >Forwarding Mechanism and Policy", Proceedings of the 8th IEEE European
> >Symposium on Security and Privacy, 2023.
>
> I think I understand what you are saying here and I agree it's worth
> documenting, but I have a few suggestions:
>
> 1.  I would reword it not to have RFC 2119 keywords in it.  As I
> understand it, these keywords are supposed to be for technical protocol
> elements, not things people do like "SHOULD consider".


Agreed that this is a good idea.

>
> 2.  I would rewrite it not to use the terms upgrade and downgrade.  I
> think the usage is confusing here.
>

Also doable to replace the upgrade and downgrade language.


>
> Finally, I don't think this is particularly unique to SPF.  If you replace
> "finds a SPF policy that covers the forwarding IPs" with something like
> finds a third party willing to sign the message, I expect I could construct
> a similar (if not quite as easy) DKIM based scenario.
>

Agreed this scenario has systemic risk, and that forwarders should
mitigate.  We could reframe this paragraph to note both scenarios.  Also
Liu et. al. paper notes this scenario in section 4.3.3.

-Wei


>
> Scott K
>
> ___
> 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

Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

[Wei Chuang]

On Sun, Aug 6, 2023 at 8:50 AM Alessandro Vesely  wrote:

> On Sun 06/Aug/2023 11:38:18 + Tim Wicinski wrote:
>
> > On Sun, Aug 6, 2023 at 7:14 AM Alessandro Vesely  wrote:
> >> On Sat 05/Aug/2023 22:24:28 + Tim Wicinski wrote:
> >>>
> >>> [...]
> >>>
> >>> 5.3.  General Record Format
> >>>
> >>> auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> >> default is "spf,dkim")
> >>>
> >>>   Indicates the supported authentication methods.  The order of the
> >> list is not significant and
> >>>   unknown methods are ignored.  Possible values are as follows:
> >>>
> >>>   dkim: Authenticate with DKIM
> >>>   spf: Authenticate with SPF
> >>>
> >>>   An empty list indicates the tag is ignored.
> >>
> >> According to the grammar below, an empty list is a syntax error.  I'd
> keep
> >> the syntax as is and remove the line mentioning an empty list.
> >
> > Good catch - but why not say "an empty list is a syntax error".  That is
> > useful (to me, others may see it otherwise).
>
>
> Yes, noting that may better readability.  Since syntax errors MUST be
> ignored, it conveys the same meaning as before, but the reason is clearer.
>

Agreed that it's fine to treat it as syntax error, and it should be
ignored.  I put in the earlier language just to have that condition
specified.
-Wei


>
>
> One last thing, how about directly assessing extensibility?
>
> dmarc-method = %s"dkim" / %s"spf" / dmarc-value
>
> Ignoring unknown methods is already in the text, so it wouldn't hurt.  I
> have no useful extension in mind, but, for DMARC-fiction examples, one
> could think of "arc", "dnswl", "dkim-atps", ...
>
> BTW, all literals in Section 5.4 miss those %s'.
>
>
> Best
> Ale
> --
>
>
>
>
>
> ___
> 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-ietf] Proposals for tolerating mailing list modifications

[Wei Chuang]

Hi all,
I just wanted to mention two proposals for tolerating mailing list
modifications as suggested in person IETF-117.  They both use ARC headers
as infrastructure, but go about tolerating mailing list modifications in
different ways.
1) Disclose and reverse mailing list transforms so that we can authenticate
those messages with the original DKIM signature:
https://datatracker.ietf.org/doc/draft-chuang-mailing-list-modifications/
2) Replay-resistant-arc draft proposes authenticating a sender defined path
from originating sender to receiver.  It also has the sender specify the
intended recipient to prevent replay amplification.  It is insensitive to
message body modifications:
https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/
Both approaches do not require trusting results in
ARC-Authentication-Results which has been a concern.  Instead they provide
signatures and values that a third party can independently and objectively
verify.  Discussion of these drafts belong on the DKIM list (
ietf-d...@ietf.org).  Also just mentioning I've heard there are other
interesting related drafts.
-Wei
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

[Wei Chuang]

At IETF-117, I restarted the proposal for a policy "auth=" tag based on the
proposal here
.
The "auth=" policy allows for restriction of SPF in scenarios where it
might be problematic but still retains its availability in DMARC by
default.  I didn't hear objections at 117, so below is some proposed
language for "auth=" for dmarc-ietf-dmarc-dmarcbis.

-Wei

=

1. Introduction, 3rd paragraph insert after first sentence:

In addition, the choice of permitted authentication methods, SPF or DKIM,
method MAY be explicitly specified, potentially to restrict the supported
authentication methods.

4.3 Authentication Mechanisms append:

Domain Owners and PSOs MAY explicitly specify the supported authentication
methods via the "auth=" tag.  The value is a colon ':' separated list of
supported authentication methods without whitespace.  The order of the list
isn't any significant,  and unknown methods are ignored. An aligned passing
result for any listed method indicates a DMARC pass.  An empty list
indicates no authentication method is specified and DMARC is disabled.  If
unspecified with a policy tag "auth=",  this indicates that both DKIM and
SPF are supported.

5.3 General Record Format insert:

auth: Indicates the supported authentication methods.  If more than one
method is specified, they are colon ':' separated without whitespace.  The
order of the list is not significant and unknown methods are ignored.  An
empty list indicates no authentication method is specified and DMARC is
disabled.
  dkim: Authenticate with DKIM
  spf: Authenticate with SPF

5.4. Formal Definition insert:

dmarc-auth =  / "dkim" / "spf" / "dkim:spf" / "spf:dkim"

Table:
Tag Name   Value Rule
auth dmarc-auth
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Proposal for additional Security Considerations for SPF Upgrade in draft-ietf-dmarc-dmarcbis

[Wei Chuang]

I noted at the DMARC session -117, that with the p=reject downgrade to
quarantine language, this increases the risk of SPF upgrade attacks due to
forwarding.  The reply was to propose language for this and below is the
suggested text for the proposed "11.9 Quarantined Forwarded Mail Security
Risk"

=

11.9 Quarantined Forwarded Mail Security Risk

When receivers apply the "MUST NOT reject" in Section 8.6 to accept
unauthenticated messages as quarantined messages, receivers SHOULD
carefully review how they forward mail traffic to prevent additional
security risk.  That is, this downgrade can enable spoofed messages that
are SPF DMARC authenticated with a fraudulent From identity despite having
an associated strong DMARC policy of "p=reject".  A malicious sender needs
two properties to perform such a SPF upgrade attack: 1) a receiver that
will forward quarantined messages, and 2) the spammer finds a SPF policy
that covers the forwarding IPs.  Such a sender crafts a message with From
header assuming the identity of the domain with the SPF policy and matching
MAIL FROM.  Consequently the receiver evaluates message authentication and
finds that the MAIL FROM does not authenticate but does not reject the
message and instead quarantines it.  Vulnerable receivers then forward the
message to some subsequent receiver with the message taking the
authenticated identity of the From header.  That forwarding may be under
control of the malicious sender perhaps via auto-forwarding or enterprise
policy.  Receivers SHOULD consider restricting forwarding when the message
is SPF unauthenticated.  SPF upgrade attack and other considerations are
discussed further in Liu et. al. [1].

[1] Liu, Enze et al. "Forward Pass: On the Security Implications of Email
Forwarding Mechanism and Policy", Proceedings of the 8th IEEE European
Symposium on Security and Privacy, 2023.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Any slides for Friday’s session?

[Wei Chuang]

A couple suggestions for slides:

   - Could Scott or someone distill Scott's comments
   
into
   a slide?
   - Could someone put what is known about "What’s needed to deal with the
   indirect mail flow problems?" into a slide?
  - I volunteer some version of the "Mailing-List Authentication
  Comparison" Google docs (link
  
)
  much summarized
  - That docs is missing two recent ideas I heard: Levine's proposal to
  wrap message message/rfc822 and Ale's proposal to provide a mailing-list
  opt-in procedure to avoid From munging.

Separate point:

   - Can the discussion on "SPF use in DMARC" include the optional "auth="
   and in particular "auth=dkim"?

-Wei

On Wed, Jul 26, 2023 at 12:29 PM Barry Leiba 
wrote:

> Other than the chars’ agenda slide, I have no slides for Friday, with a
> plan of just discussing ideas and text — so everyone, please do read the
> text proposals and be prepared to discuss them.
>
> That said, if anyone has slides to propose, please do so by end of the
> work day Thursday.  I do not plan to approve any slides posted after 6pm
> San Francisco time on Thursday.
>
> Barry
>
> ___
> 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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Wei Chuang]

On Sun, Jul 16, 2023 at 6:50 PM Emanuel Schorsch  wrote:

> Having negotiations between senders, evaluators and lists sounds
> difficult. I agree the dream would be to have at least a semi-automated
> solution which works. I'd be interested to hear what you think of the
> following rough idea (with the assumption that most lists today are
> currently doing FromMunging on p=reject domains):
>
>- By default FromMunging remains the practice without special
>information.
>- MailingLists add ARC Headers and an additional header for what the
>unmunged FromHeader was (with some agreed on standard, e.g. Wei's
>proposal
>
> 
>  to
>use `Prior-From`).
>
> Apologies that the draft-chuang-mailing-list-modifications I-D is in rough
-00 form i.e. there's some more clean up needed.  And agree in hindsight
that the draft should be based in ARC (RFC8617) and separately call out how
it modifies draft-chuang-replay-resistant-arc.

-Wei


> This gives the information needed to evaluators to undo the fromMunging on
> their end. Evaluators can check the original authentication in case the
> list does not enforce authentication checks. More importantly, evaluators
> can undo the fromMunging and restore the original header within the
> evaluators system. This can be based on an explicit system (user manually
> adds a setting that this list is trusted), or an implicit system (evaluator
> sees that the list is trustworthy in general, or that is implicitly trusted
> by the specific recipient).
>
> This would place a burden on MailingLists (to add Arc headers and original
> FromHeader) and would place a burden on evaluators (to have a refined
> evaluation method with a nuanced understanding of "trust" in lists). It
> seems if both parties showed interest it would be a tractable solution. A
> nice aspect of this solution is that I don't believe these changes would
> break non-participants, and gradual adoption by individual lists /
> evaluators would show benefits.
>
> Emanuel Schorsch
>
> On Sun, Jul 16, 2023 at 1:51 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> As long as the unsympathetic evaluator produces a reject or bounce, the
>> automatic digest approach will work well.   if digest mode failover is
>> implemented as an operator function, it could be implemented quickly
>> without software changes .   Automating the process seems like a minor
>> undertaking as well.   If the evaluator does silent discard, your approach
>> depends on the evaluator noting that messages are missing.
>>
>> To get out of digest mode, the user still needs to negotiate with his
>> evaluator.   You are despondent on that point, I am more hopeful,
>> especially for this particular list's participants.   For the negotiation
>> to be successful, I think the user will need the information I discussed,
>> including:   a commitment of 100% sender authentication prior to
>> forwarding, a definition of how the evaluator can identify list traffic,
>> and clarity about what content filtering is or is not done before
>> forwarding.   We don't want the list to be blacklisted simply because the
>> evaluator has stricter content filtering than the list provides.
>>
>> Both your approach and mine will isolate the problem to unsympathetic
>> evaluators and their unfortunate users.   Both approaches know that we must
>> either modify the evaluator's filtering rules or live within those rules.
>>  Neither of these two approaches requires asking senders to lower their
>> security posture from p=reject to p=none., and both eliminate From munging,
>> which is a big win.
>>
>> Doug Foster
>>
>>
>> On Sun, Jul 16, 2023 at 9:25 AM Baptiste Carvello <
>> devel2...@baptiste-carvello.net> wrote:
>>
>>> Hi,
>>>
>>> Le 15/07/2023 à 12:22, Douglas Foster a écrit :
>>> > [...]
>>> > Track 2: Exception Request
>>> > [...]
>>> > Track 2 benefits:
>>> > [...]
>>> > - Elimination of From munging is potentially available to all
>>> > participants, even those from p=reject domains
>>>
>>> This important word here is "potentially". In practice, only an
>>> insignificant part of this potential can be achieved, because your plan
>>> heavily relies on non-automatable human work, and on end users being
>>> able to weight into their providers' policies.
>>>
>>> Thus for all practical purposes, "conditional munging" is equivalent to
>>> plain munging.
>>>
>>> Therefore I propose Track 3:
>>>
>>> 1) We undo existing munging.
>>>
>>> 2) We inform end users that, if they do not receive messages from
>>> certain senders (especially those senders whose addresses were
>>> previously munged), they can regain them by switching their subscription
>>> mode to "digests", at least temporarily while their mailbox provider
>>> fixes their DMARC handling.
>>>
>>> 3) Whenever we get bounces, we configure our software to forcibly switch
>>> the offending users (I mean the receive

Re: [dmarc-ietf] Another p=reject text proposal

[Wei Chuang]

FWIW I think this language is an improvement over the prior language but I
would like to point out two concerns:

1) Specifying receivers with "MUST NOT reject" in Section 8.6
"Interoperability Considerations" presumably to to downgrade a p=reject to
quarantine with does carry new security risk.  I note that "other knowledge
and analysis" is not defined and there may be a temptation to blindly do
downgrades.  I believe the document needs to note that new risk in that
Section 5.8 "Policy Enforcement Considerations" [1] and Section 11
"Security considerations" so that receivers apply the downgrade in secure
way.   Section 5.8 already does note risk for the immediate recipients as
says "it may increase the likelihood of accepting abusive mail" however it
should note risk in forwarded flows and the risk to those recipients.  In
particular I'm worried about SPF upgrade attacks as described by Liu et.
al. [2].  Here an adversarial senders may exploit overly broad SPF policies
of victim domain that permit SPF upgrade as noted Section 4.2.2 in plus
relaxed DMARC to enable DMARC From header spoofing.  The paper notes that
some receivers today may relax DMARC as a user setting to improve
deliverability i.e. permit downgrading a p=reject enforcement to
p=quarantine in Section 4.2.3 and another setting to forward messages as
described in Section 4.3.1.  Liu et al. was able to demonstrate sending
spoofed state.gov emails that passed DMARC at the receiver despite a
"p=reject" policy using those steps as described in Section 5.  Presumably
receivers that then more broadly apply DMARCbis p=reject downgrade may
inadvertently create a new vector for SPF upgrade attacks.  Some
suggestions are for receivers to be cautioned against doing p=reject
downgrades if they don't validate participation by the forwarding
recipient.  Another is if DMARCbis adopts some scoped authentication, is
for domains to deploy a DMARC DKIM-only authentication policy.  This not
some academic issue and the spammers are very aware of SPF upgrade attack
technique i.e. looking for ways to exploit it.  We've seen significant
scaling of this type of attack over the past two years or so.

2) The proposed language calls out "“alumni forwarders”, role-based email
aliases, and mailing lists" for consideration by receivers.  How should
receivers be aware that traffic failing authentication should be
reconsidered?  Mailing-lists sometimes uses RFC2919 List-id headers.  Can
Section 5.8 [1] call out more strongly the application of those List-id
headers?  Can something be done so that receivers can identify the other
scenarios e.g. role-based email aliases and alumni-forwarders?

[1] DMARCbis:
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-28
[2] Liu, Enze, et al. "Forward Pass: On the Security Implications of Email
Forwarding Mechanism and Policy", 8th IEEE European Symposium on Security
and Privacy, 2023, https://arxiv.org/abs/2302.07287

-Wei

On Thu, Jul 6, 2023 at 7:55 AM Barry Leiba  wrote:

> I had some off-list discussions with Seth, who was very much against
> my original proposed text, and he suggested an alternative
> organization that would be more palatable to him.  I've attempted to
> set that out below.  The idea is to remove the normative requirements
> about using p=reject from Sections 5.5.6 and 5.8, and instead put a
> broader discussion of the issues, along with the normative
> requirements, into a new "Interoperability Considerations" section.
> This makes it explicitly clear that any MUST/SHOULD stuff with regard
> to using and honoring p=reject is an issue of interoperating with
> existing Internet email features.  I can accept that mechanism also,
> and so, below is my attempt at writing that proposal up.
>
> Barry
>
>
> -
>
> — Section 5.5.6 —
>
> ADD
>In making this decision it is important to understand the
>interoperability issues involved and problems that can result for
>mailing lists and for deliverability of legitimate mail. Those
>issues are discussed in detail in the Interoperability
>Considerations section [see Section x.x].
> END
>
> — Section 5.8 —
>
> OLD
>Mail Receivers MAY choose to accept email that fails the DMARC
>mechanism check even if the published Domain Owner Assessment Policy
>is "reject".  In particular, because of the considerations discussed
>in [RFC7960], it is important that Mail Receivers SHOULD NOT reject
>messages solely because of a published policy of "reject", but that
>they apply other knowledge and analysis to avoid situations such as
>rejection of legitimate messages sent in ways that DMARC cannot
>describe, harm to the operation of mailing lists, and similar.
> NEW
>Mail Receivers MAY choose to accept email that fails the DMARC
>mechanism check even if the published Domain Owner Assessment Policy
>is "reject".  In particular, because of the consid

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

[Wei Chuang]

The data we presented June 20th (archive
)
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
.
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

).

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 
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 t

Re: [dmarc-ietf] DMARC and Data Hygiene

[Wei Chuang]

On Tue, Jun 20, 2023 at 8:18 AM Scott Kitterman 
wrote:

> I am starting a separate thread, because this isn't just about SPF.
>
> I think the criticism of the reliability of SPF data is valid, but I think
> DKIM is similarly problematic.  Once you get rid of SPF, you'll find you
> haven't really solved much.  The next logical step will be to get rid of
> DKIM.
>
> DKIM has man wonderful features, but the bottom line for DMARC is a valid
> DKIM
> signature indicates that the mail was sent (at some point) from an MTA
> that
> was authorized by the signing domain.  This is what a SPF pass result
> means
> too.  DKIM has broader utility in DMARC because it can persist through
> some
> indirect mail flows, but either way, an SPF pass and a valid DKIM
> signature
> both mean the message was authorized by the domain in the relevant
> identity.


> The particular SPF problem that's being the focus of some much attention
> is
> addressed in the RFC 7208 security considerations (See section 11.4).
>
> DKIM has a similar, but different problem.  The DKIM replay problem is bad
> enough that the IETF has chartered a working group to try to address it:
>
> https://datatracker.ietf.org/doc/charter-ietf-dkim/


I would argue we can see a difference in the SPF and DKIM attacks with
respect to spoofing and that makes a difference for phishing.  With the SPF
upgrade attack, the adversary can spoof an arbitrary identity in the victim
domain and have it SPF authenticated.  See [1] for examples.  With DKIM
replay, the adversary needs access to an account in the victim domain to
obtain a signed message, but can't arbitrarily spoof some other identity in
the victim domain.

At a fundamental authentication property level, there are additional
differences too.  IPs tend to be shared more than private keys. Proving an
IP based validation to a third party is harder than with a digital
signature.  (This is one the issues of trusting the SPF results in
ARC-Authentication-Result, whereas with DKIM once can try to validate the
signature yourself).  On the other hand it's only fair to make
the observation that SPF is easier to set up than DKIM and we want to
capture those benefits as well.

We're definitely not saying SPF should be deprecated, and in fact we want
more deployment of SPF as it's highly complementary to DKIM both from a
deployment perspective but as a spam fighting signal.  We just want to
prevent its use in From header spoofing.

[1] https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf


>
>
> I'll lay out examples to demonstrate:
>
> Case 1 - First Party Only
>
> An organization only authorizes email to be sent from MTAs it directly
> controls (I know this mostly doesn't exist, but it's useful to show where
> the
> problems are).  The organization does not send email for any third parties.
>
> In this case, as long as the organization can limit sending to authorized
> users, the quality of both SPF and DKIM pass results should be well
> aligned
> with the nature of the mail the organization sends.
>
> Case 2 - Sender For Others, Own Domain
>
> An domain uses it's own domain to send mail for others (like all webmail
> providers).  The domain's email is sent using it's own infrastructure, so
> it
> doesn't need to worry directly about third parties.
>
> In this case, there's still no real risk of external forgery, so an SPF or
> DKIM pass means it was sent by the domain.  The risk is to the domain's
> reputation if users sign up and use the service to send "bad" mail.
>
> If the domain fails to prevent 'bad' messages from being sent, then these
> 'bad
> messages get a DMARC pass.  The mail is sent through the authorized email
> server, so it gets SPF pass and a valid DKIM signature.
>
> This is a particular threat for DKIM, because once this succeeds for a
> single
> message, the user can replay the message on third party infrastructure to
> send
> it to large numbers of recipients.  This is the core issue the DKIM
> working
> group was resurrected to address.  It is not, however, clear that there's
> a
> protocol solution to this problem and the group has been pretty quiet
> recently.
>

Just pointing out we're prototyping one of the drafts and there's
other work behind the scene.


> Case 3 - Sender For Others, Their Domain
>
> When organizations authorized third parties to send on their behalf (by
> publishing an SPF record or a DKIM public key record in DNS), they are
> trusting their domain's reputation to those third parties.
>
> In particular, they are at risk of those third parties doing poor inbound
> validation and other customers of the authorized third parties injecting
> 'bad'
> mail authorized by their domain.
>
> This is where I think the focus of recent discussion has been.
>
> In these cases, email is emitted via third parties and passes SPF (may
> also be
> DKIM signed, but I suspect it's less common because replay is easier), so
> it's
> authorized, but unwanted.
>
> Case 2 and Case 3 are bot

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Wei Chuang]

As DMARC is intended to protect the From header from spoofing, we support
moving DMARCbis authentication to DKIM-only due to the recent demonstration
of such spoofing that was enabled by an SPF upgrade attack as described in
[1].  That paper cites the vulnerability of Federal government, financial,
commercial and other senders to phishing attacks.  (Anecdotally we spot
checked some 10 financial companies for a different reason, and found 3 of
them were similarly vulnerable).  So it's really important to mitigate this
vulnerability from DMARCbis.  That said, we really want to emphasize that
SPF is still very useful and important for email authentication as it is a
rather important part of a portfolio of authentication signals for Gmail,
and has a complementary role to DKIM in our system.   In fact, our
forwarders guidance calls for supporting DKIM and SPF [2], and this is
really true for any traffic (forwarded or from some originator) to Gmail.

Our email authentication numbers roughly look similar to other large
senders.  Our DMARC percentages are as follows (queried over a week), and
qualified as accepted messages.

DmarcPolicy

count

REJECT

45.60%

absent

22.73%

NONE

18.78%

QUARANTINE

12.89%

100.00%

We then look at DKIM and SPF authentication rates (and independent of
DMARC).  The following numbers come from deeper in the delivery pipeline
after being accepted and evaluating DMARC policy.  We see that SPF provides
coverage for DKIM authentication gaps.  The following table shows the
percentage of messages with SPF pass (true/false) and RFC8601
 DKIM
authentication-results.  Of this traffic, DKIM is not passing for 5.56% and
there's SPF coverage for 4.78%.  A large cause for this is messages that
were not DKIM signed but could be validated with SPF at 3.91%.

ConcatSpfPassDkimAuthResults

SUM of

TRUE,PASS

92.58%

TRUE,NEUTRAL

3.91%

FALSE,PASS

1.85%

FALSE,NEUTRAL

0.72%

TRUE,FAIL

0.69%

TRUE,TEMPERROR

0.17%

FALSE,FAIL

0.05%

FALSE,TEMPERROR

0.02%

TRUE,POLICY

0.00%

FALSE,POLICY

0.00%

Grand Total

100.00%

When we break up this traffic by distinct domain counts, the view is
different.  There notably appears to be many more senders for DKIM than SPF
which is surprising (DKIM: 73.26%, SPF 35.34%).  We haven't analyzed this
further but there may be many more DKIM capable senders than previously
thought.  Unfortunately one hypothesis is that many of these senders are
spammers that are able to use authentication more proactively than regular
senders.  Even so, the DKIM not passing rate is 26.74%, and SPF can provide
coverage for 17.41%.

ConcatSpfPassDkimAuthResults

SUM of

FALSE,PASS

55.33%

TRUE,PASS

17.93%

TRUE,NEUTRAL

15.30%

FALSE,NEUTRAL

7.58%

TRUE,FAIL

1.09%

TRUE,TEMPERROR

0.98%

FALSE,FAIL

0.97%

FALSE,TEMPERROR

0.76%

TRUE,POLICY

0.04%

FALSE,POLICY

0.02%

Grand Total

100.00%

Because from these numbers, we can see that SPF does provide significant
coverage when DKIM is not present, so we need to find a bridging process if
we are to move to DKIM-only for DMARCbis.  Our proposal would be for
DMARCbis to maintain the default for SPF and DKIM support, and to support
senders that want to drop SPF as one of their DMARC authentication methods
to avoid the SPF upgrade vulnerability.  We could have a DMARC policy tag
for authentication e.g. "auth=" that describes the permitted authentication
methods the sender supports and receiver MUST use for validation.   DKIM or
SPF are represented as tags "dkim" and "spf", and if multiple tags are
present then they are comma separated and any one passing is considered
passing authentication.  Also at least one authentication method MUST be
present.  Other authentication methods could be added in the future as it
is our hope that there will be some other authentication method to improve
upon and someday replace SPF.  overall.  If "auth=" is missing, then DMARC
falls back to supporting SPF and DKIM.

The proposed deployment process would be that senders at higher risk from
>From header spoofing will invest in deploying DKIM and will declare
authentication as DKIM-only.  SMB senders can still bootstrap their DMARC
deployment by using SPF but hopefully will lower their risk by avoiding the
SPF include policy patterns described in [1].  In order to bring together
these new configurations over the long term, DMARCbis might want to define
a "DMARC2" configuration that symbolically defines the end authentication
goal e.g. it might be the "retirement" of SPF.

-Wei on behalf of the Gmail security team

[1] https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf
[2]
https://support.google.com/mail/answer/175365?sjid=1196932423118655843-NA

On Mon, Jun 19, 2023 at 11:42 AM Patrick Ben Koetter  wrote:

> * Alessandro Vesely :
> > On Thu 15/Jun/2023 23:25:44 +0200 Tero Kivinen wrote:
> > >
> > > I rerun the statistics and yes, there is 0.84% cases where dkim
> > > failed, but 

Re: [dmarc-ietf] Third party signatures

[Wei Chuang]

That's a good point around ARC as that's what it was meant to do.  And that got
me thinking that it might be helpful to systematically compare the
different proposed approaches and their pros and cons.  The next approach
would be to consider the general approach of the reversible transform idea
that several folks have proposed, and how that would look.  And that got me
rethinking the "DARA" work that we're already prototyping for DKIM replay
mitigation, if it can relate to mailing-list and forwarder modifications
and I now think DARA can help here too. The three different approaches have
distinct pros and cons.

The following is a summary of the comparison.  Attached is a more detailed
comparison as PDF that tries to work through what the algorithms would
likely do.
ARC
Use ARC to override the SPF and DKIM results at Receiver by those found at
the Forwarder.

Pros:

   -

   Uses existing SPF, DKIM and ARC standards.
   -

   Tolerates header and body modifications

Cons:


   -

   Receiver must trust the ARC headers generated by the forwarder.
   -

   Receiver must trust the modifications the forwarder made.
   -

   Receiver must trust that no ARC replay occurred


Transform

Proposed in draft-kucherawy-dkim-transform
 where
the forwarder can specify a "tf=" tag that specifies addition of Subject
header prefix, text footer to a mime-part, mimify plaintext, and adding a
mime-part representing a footer to an existing mime-tree to the
DKIM-Signature.  These all may be reversed to recover the original
signature.

DKIM-Signature: d=...; tf=subject,mime-wrap,

The ideas in draft-vesely-dmarc-mlm-transform-07

are conceptually similar though add support for ARC.

Pros:

   -

   Tolerates header and body modifications
   -

   Identifies the modifications
   -

   Does not require particular trust of the forwarder to be non-malicious

Cons:

   -

   Receiver must trust that no DKIM replay occurred
   -

   Might not compose across multiple modifying forwarders
   -

   Might not support all possible modifications by forwarder
   -

   Reversing all possible draft transformations is potentially complicated


DARAThis clarifies the DARA ideas in draft-chuang-replay-resistant-arc
 which
calls for authenticating a path from the Originator through the Forwarder
to the Receiver that's tolerant of modifications.  Some ideas of a
validated path are explored in draft-levine-dkim-conditional
.

Pros:

   -

   Tolerates header and body modifications
   -

   Does not require particular trust of the forwarder to be non-malicious
   -

   Supports arbitrary many forwarders that may modify the message
   -

   Supports protocol unaware participants

Cons:

   -

   Requires DNS policy lookup on outbound delivery
   -

   Requires additional messages DKIM signing to support Bcc/Mailing-list
   recipients (each get their own signed copy)
   -

   Builds upon ARC which is considered complicated


-Wei


On Sat, May 6, 2023 at 7:42 AM John R Levine  wrote:

> > It is not a commitment at this time.  That said, we are interested in
> > solving this problem and welcome collaboratively figuring out the right
> way
> > to do this.
>
> It seems to me that ARC provides the useful parts of third party
> signatures and, while rather complicated, has the benefit of actually
> existing.  The chain of authority runs from the relay host back to the
> original rather than the other way around, but that's a lot easier to do
> mechanically.
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> "I dropped the toothpaste", said Tom, crestfallenly.
>


Mailing-List Authentication Comparison (ietf-dkim).pdf
Description: Adobe PDF document
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third party signatures

[Wei Chuang]

On Tue, May 2, 2023 at 10:21 AM Murray S. Kucherawy 
wrote:

> On Tue, May 2, 2023 at 10:06 AM John Levine  wrote:
>
>> No large provider has ever expressed any interest in either so I cannot
>> see any reason to spend more time on either one.
>>
>
> I believe Wei has expressed interest in the transforms stuff, but I don't
> recall whether that was a commitment to implement and experiment.  I know
> how engineers at big companies are.  :-)
>

It is not a commitment at this time.  That said, we are interested in
solving this problem and welcome collaboratively figuring out the right way
to do this.
-Wei


>
> -MSK, participating
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third party signatures

[Wei Chuang]

On Mon, May 1, 2023 at 8:23 PM Murray S. Kucherawy 
wrote:

> Some thoughts about the third party signature discussion that happened
> over the last couple of weeks while I was away:
>
> I wrote ATPS as an experiment in 2012.  At the time we were still
> finishing DKIM (RFC 6376 was only five months earlier), and still talking
> about whether a third party signing solution was even possible.  Doug Otis
> had a similar "TPA" draft out at the time, but neither of us were getting
> any traction from the working group.  The community was quite dubious that
> the general idea could work, and TPA had a lot of complexity to it that I
> thought we could do without (or, at least, if we did need it, we could add
> it in later).  Since I had an open source platform to play with, I decided
> to implement something, include it in the platform, ship it, and see what
> happens.  I managed to get an AD to sponsor what became RFC 6541 to
> encourage other implementations to try it.
>
> In the years that followed, I think I only ever saw one consumer of that
> platform, other than me, enable the ATPS feature and try it out.  I know of
> only Hector's code as another implementation.  There have been claims that
> it was not "marketed" well, but I never saw any of this as something in
> need of marketing.  If it's a feature people needed, they would ask for it
> and turn it on, and we would hear that it solved a problem.  It wasn't hard
> to configure.  To me, that doesn't say we did a poor job of "marketing" it,
> but more that a path to its success wasn't clear in the contexts where we
> really needed it.
>
> There are two main reasons I can see for this, as both an implementer and
> a consumer of this stuff, when it comes to mailing lists and the DMARC
> problem:
>
> (1) Scale.  For mailing lists, ATPS only works if you list in your DNS all
> other domains that run lists to which your users subscribe.  If you have a
> handful of users, you might be able to work this out.  If you have a GMail
> number of users, you now have giant problems of user support and keeping
> that list current: "You mean I have to register every domain where I join a
> list?  This sucks!"  "I forgot to de-register a domain years ago, sorry.
> (And now that domain is still an authorized third party.)" "I typed the
> domain name wrong, how come it doesn't work?"  "Why can't you auto-detect
> all of this?"
>
> (2) Security.  ATPS doesn't specify what stuff the third party will
> generate as you.  That third party now, practically, has one of your
> signing keys.  Suppose you decide you trust the domain owner; do you trust
> the list?  If you declare through ATPS that you trust ietf.org, and the
> list server here doesn't validate mail at ingress, then I can send
> unauthenticated mail through the list as you and it'll be as valid as if
> you signed it yourself.  That might be OK for a marketing partner you're
> paying, but it's not awesome for free mailing lists.
>

Just wanted to voice agreement on both key points.


>
> So I don't think it really helps us here, at least not in its current
> form.  Unless I've misunderstood the proposal, amending ATPS to be a
> per-user thing only trades some of the second problem for more of the first
> problem.
>
> And I think the conditional signatures ideas suffer from the same two
> issues I identified above.
>
> I also have a vague inkling that we shouldn't be talking about ATPS in a
> DMARC document because that's a layering violation, in the sense that DMARC
> is built atop DKIM and SPF, and ATPS augments DKIM.  We might get away with
> saying something like "You ought to consider things that make DKIM more
> list-tolerant", but forcing people to undertake all the DNS and user work
> that ATPS entails drags a lot of stuff into DMARC that we probably don't
> want.
>
> Personally, I think the DKIM transforms drafts stand a better chance of
> success.  They need implementation and integration with a willing MLM, and
> some experimental deployments, to see for sure.  The notion of DKIM
> transforms is also a long shot because of the complexity with which lists
> modify messages.
>

Also agreement in these points.

One possible way to understand this space might be to create a table on
trust relationships.  For example, an enterprise domain conceptually might
be willing to have an outbound gateway sign on its behalf or be willing to
delegate via something like ATPS.  Potentially there might be a similar
relationship for ESPs and their customers.  Other senders will have a
much more restrictive trust relationship.  And this is all in the abstract
as others on this list understand outbound gateway and ESPs understand
their respective members of the mailflow better than I do.

As for DKIM transforms, I just wanted to suggest that this ought to be
future work for DKIM WG.

-Wei


>
> This is not me saying we should pivot to work on these other things, at
> least not right now.  I'm just skeptical that ATPS as defined 

Re: [dmarc-ietf] list history, Signaling MLMs

[Wei Chuang]

On Sat, Apr 15, 2023 at 1:40 PM Scott Kitterman 
wrote:

>
>
> On April 15, 2023 8:17:41 PM UTC, John R Levine  wrote:
> >> I'm assuming that the "long list of stinky possible workarounds" are
> the existing "whatever" mitigations, and rewriting seems to be acceptable
> enough as a mitigation to convince large [enterprise] mail systems to move
> forward with restrictive policies. ...
> >
> >I think you are greatly overestimating the connection between cause and
> effect here.  The people setting the policies have no idea what effect they
> have on their users, and to the degree they do, they do not care. IETFers
> at large organizations who support their IETF work, and that have p=reject,
> tell me they've told the IT departments that the policy is making it hard
> for them to get their work done and the response is either "duh?" or "not
> our problem."
> >
> >> I intentionally published > "p=quarantine pct=0" specifically to find
> the MLMs that implemented no mitigations, weighed that against what I knew
> about which receivers enforced non-mitigated mail, and then made a judgment
> call to move forward.
> >
> >It sure would be nice if people at other organizations were as concerned
> about the quality of mail service to their users.  But noo.
> >
> >> I believe Wei suggested that we need to find a better "whatever" (in
> the form of an alternative to SPF and DKIM that works with mailing lists)
> ...
> >
> >I would like a pony, too.  But ARC is as good as we have now and after a
> decade of beating our heads against the wall, I don't think we're going to
> find anything better.  I've suggested a bunch of things that would make
> lists' life better, and nobody is interested:
> >
>
> Agreed.
>
> If someone has a great idea for a third way in email authentication, they
> should develop the idea, get some deployment experience, and then document
> the protocol.  After that would come the question of adding it to DMARC.
> This is not the working group to do that work.
>

Agreed such a proposal shouldn't be worked on in DMARC.  Also agreed that
it's a good idea to get deployment experience.  That said, I think there is
a lot of value in getting early IETF feedback in some other
forum/mailing-list to help review the potential proposals.

-Wei


>
> Scott K
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists

[Wei Chuang]

On Mon, Apr 10, 2023 at 9:55 AM Murray S. Kucherawy 
wrote:

> On Mon, Apr 10, 2023 at 8:15 AM John Levine  wrote:
>
>> > For certain
>> >constrained but hopefully reasonable scenarios of mailing list
>> >modifications, we might be able to distinguish the sources of content.
>>
>> People have been suggesting this forwver, but it really doesn't scale.
>> There are a lot more list hosts with a lot more configurations that
>> any of us have individually ever seen. In many cases they add or
>> rewrite MIME parts which is extremely hard to unwind enough to see if
>> a DKIM signature would have been valid.
>>
>
> I have to agree.  For as many times as this notion has been proposed, it's
> never been given serious consideration, and this is the reason: We can't
> possibly describe all the MLM mutations that exist, even if the mechansim
> for doing so is made extensible.
>
> I think the one thing we haven't discussed is: Could the 80-20 rule apply
> here?
>

+1


> That is, if we start off with something like what
> draft-kucherawy-dkim-transform proposed (or even a trivial subset of it),
> might it make enough of a dent to get us through this stalemate, and then
> we can figure out what to do with the rest of it?
>

+1 I think that's a good start or some subset.
-Wei


>
> -MSK, participating
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists

[Wei Chuang]

On Mon, Apr 10, 2023 at 8:15 AM John Levine  wrote:

> It appears that Wei Chuang   said:
> >1) We know that a sender intends to send a message down some path that may
> >include a mailing list, that got to me safely.  This is to avoid DKIM
> >replay and FROM spoofing attacks.
>
> I think we can do that by looking at the To/Cc addresses to check if
> they include the list that forwarded the mail.
>

+1 One approach might be to chain together recipients/sender pairs across
forwarders, and sign the recipients. (Another approach might be to tie
together SMTP transactions between sending-service/receiving-service pairs)


>
> >2) That we can identify the contributors to the content of the message in
> >that path to distinguish malicious vs benign contributors.
>
> Isn't that what ARC is for? You can look back through the list headers
> to see what the state of the message was like on the way in. While I
> am not a fan of applying DMARC policies to the output of forwarders
> like mailing lists, they work to filter inbound mail to a list.


With ARC and a modifying mailing list, we hopefully will see that an
expected DKIM-signature fails and hopefully at least a terminating
ARC-Message-Signature that passes.  With these tools, the receiver isn't
able to see which part of the message was contributed by the sender vs the
mailing list.   If there's spammy content, the receiver can't distinguish
which party contributed to that content, then so has to attribute that
spammy content to both parties, but at the cost of harming the innocent
one.  Despite that issue I should mention that ARC/DMARC still helps us in
knowing who your sender is, which is helpful.

-Wei


>
> > For certain
> >constrained but hopefully reasonable scenarios of mailing list
> >modifications, we might be able to distinguish the sources of content.
>
> People have been suggesting this forwver, but it really doesn't scale.
> There are a lot more list hosts with a lot more configurations that
> any of us have individually ever seen. In many cases they add or
> rewrite MIME parts which is extremely hard to unwind enough to see if
> a DKIM signature would have been valid.
>
> R's,
> John
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] AOL-compatible mailing lists

[Wei Chuang]

On Sun, Apr 9, 2023 at 2:28 PM Murray S. Kucherawy 
wrote:

> On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> As an evaluator, what I can accept is that "Some intermediaries could be
>> allowed to make some changes y do want unrestricto messages, if I have a
>> list of intermediaries that should be allowed, sufficient reason to trust
>> what they propose to do, and a reliable way to identify them."I do
>> exceptions all the time.   But lists don't want to make special
>> arrangements with evaluators, and don't want to make special arrangements
>> with senders.  Apparently, lists don't even want to do rigorous
>> verification to ensure that a post comes from the purported subscriber.
>>  But theted access to evaluators that filter based on simplistic triggers
>> like "p=reject".
>>
>
> I see two issues with this line of thinking:
>
> (1) "I do exceptions all the time" works when you are a relatively small
> operator with a relatively small user base for whom you need to configure
> exceptions.  You can get away with doing those manually.  What size staff
> do you imagine GMail would need to hire to investigate and configure manual
> exceptions on a timely basis for each time one of its billion-plus users
> wants to subscribe to a mailing list?  The notion screams for automation,
> and automation screams for something deterministic or at least close to it
> upon which to base automated decisions.  That last bit is what's missing
> here.
>

+1


> (2) "But lists don't want to make special arrangements with evaluators,
> and don't want to make special arrangements with senders".  They might, if
> there existed a reliable way to do so.  How would you accomplish this in a
> way that prevents an attacker from making you think he's a list, and then
> sending whatever he wants from inside that trust boundary?
>

+1

FWIW I'm starting to think this problem has two parts:
1) We know that a sender intends to send a message down some path that may
include a mailing list, that got to me safely.  This is to avoid DKIM
replay and FROM spoofing attacks.
2) That we can identify the contributors to the content of the message in
that path to distinguish malicious vs benign contributors.  For certain
constrained but hopefully reasonable scenarios of mailing list
modifications, we might be able to distinguish the sources of content.  If
necessary, we can go back to first principles to determine which
modifications have to be supported.  For example I've seen Brandon mention
that mailing list appending disclosure footers are required for compliance
sometimes.  Others hopefully we would not have to support to reduce
implementation complexity.


>
> I think evaluators SHOULD NOT block on simplistic rules like p=reject,
>> because a correct p=reject block requires follow-on work to block
>> everything else from that malicious source, and should not be done
>> incorrectly.   They should review, either with pre-quarantine or
>> post-audit, which is what I do.  I have no problem with
>> disposition=quarantine, even for p=none.   I am obligated to protect my
>> users, while also obligated to provide my users the messages they need, not
>> the ones that are technically optimal   I don't understand why Big Tech and
>> its A.I. tools cannot be deployed to do the best thing.
>>
>
Simplistic rules are more likely to be deterministic and interoperate in an
understandable way.   Permitting exceptional cases and AI tools introduces
complexity and variability as exceptions are given and AI models change.

-Wei


> I'm pretty sure they could, for their own use cases.  But what about the
> operators in between, who aren't Big Tech and don't have AI tools?  A
> standard has to work for everyone.
>
> -MSK, participating
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC interop and abuse concerns

[Wei Chuang]

On Wed, Mar 15, 2023 at 5:05 AM Scott Kitterman 
wrote:

>
>
> On March 15, 2023 6:55:15 AM UTC, Wei Chuang  40google@dmarc.ietf.org> wrote:
> >On Tue, Mar 14, 2023 at 9:11 AM Scott Kitterman 
> >wrote:
> >
> >> For the replay resistance part of the question, I think it would make
> >> sense to wait and see how the DKIM working group addresses the problem
> for
> >> DKIM generally and then assess how their solution impacts ARC and how it
> >> addresses the issue for ARC.
> >>
> >> I think the question of spamminess is orthogonal to the authentication
> >> questions that ARC attempts to answer.  It's subjective, so I don't
> think
> >> it can really play into ARC.
> >>
> >> Additionally, if the intermediary thinks a message is bad (spam), then
> the
> >> solution is to not send the message onward and try to make it someone
> >> else's problem.
> >>
> >
> >Likely the issue is that the intermediary doesn't think of the specific
> >message as being spam, yet is worried about the possibility of
> >authenticating spam so drops ARC for some scenarios. The receiver still
> >could benefit from seeing the Authentication-Results of the intermediary.
> >In other scenarios, the ARC headers are intentionally broken by a spammer.
> >Should non-malicious forwarders of those messages still generate ARC
> >headers?  Keep in mind, the forwarder again might not realize the message
> >is spammy
>
> I think this may get to the core of the issue.
>
> ARC doesn't provide any authentication itself, it's a mechanism for
> forwarding the received authentication.  If people are thinking of ARC as
> providing authentication, I don't think they are looking at it correctly.
>
> Any receiver (either original or post-ARC) shouldn't assume that the ARC
> results are in any way related to classification of a message as spam/not
> spam.  ARC from a trusted relay can yield an identity to use as an input
> for domain reputation, which can aid in classification, but that's two
> critical steps away from the ARC data in the message:
>
> 1.  Knowing if the source of the ARC data is sufficiently trustworthy to
> believe the data (since, as you say, the bad guys lie).
>
> 2.  Having a useful set of domain reputation data.
>
> Neither of those items are ones that can be 100% accurate.  ARC isn't a
> protocol that produces a definitive result that can be used to mechanically
> alter message delivery that people would like for it to be.
>

Agreed.


> In contrast to DKIM, ARC signing a message doesn't imply taking
> responsibility for the message.  It implies accurately communicating the
> DMARC status that was received.  I don't know how to communicate that
> effectively to the people making design decisions about mail systems.  I
> doubt they generally read IETF mailing lists (or RFCs).
>

While established forwarders that already generate ARC headers may or may
not pay attention to the IETF mailing lists, forwarders that want to set up
ARC will come visit and look up the RFCs.  So I would argue there is value
in creating a BCP.  If the IETF effort bar is high due to the rigor
involved, then perhaps something more light weight at M3AAWG to start
with?

-Wei


>
> Scott K
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC interop and abuse concerns

[Wei Chuang]

On Wed, Mar 15, 2023 at 4:02 AM Alessandro Vesely  wrote:

> On Wed 15/Mar/2023 07:55:15 +0100 Wei Chuang wrote:
> > On Tue, Mar 14, 2023 at 9:11 AM Scott Kitterman 
> wrote:
> >
> >> For the replay resistance part of the question, I think it would make
> >> sense to wait and see how the DKIM working group addresses the problem
> for
> >> DKIM generally and then assess how their solution impacts ARC and how
> it
> >> addresses the issue for ARC.
> >>
> >> I think the question of spamminess is orthogonal to the authentication
> >> questions that ARC attempts to answer.  It's subjective, so I don't
> think
> >> it can really play into ARC.
> >>
> >> Additionally, if the intermediary thinks a message is bad (spam), then
> the
> >> solution is to not send the message onward and try to make it someone
> >> else's problem.
> >
> > Likely the issue is that the intermediary doesn't think of the specific
> > message as being spam, yet is worried about the possibility of
> > authenticating spam so drops ARC for some scenarios. The receiver still
> > could benefit from seeing the Authentication-Results of the
> intermediary.
> > In other scenarios, the ARC headers are intentionally broken by a
> spammer.
> > Should non-malicious forwarders of those messages still generate ARC
> > headers?  Keep in mind, the forwarder again might not realize the
> message
> > is spammy
>
>
> I think running at least a minimal, conservative filter so as to drop
> blatant
> spam, phishing and viruses is de rigueur.  Otherwise you're akin to an
> open relay.
>
> That said, ARC is still preferable in stead of DKIM as it doesn't involve
> /claiming some responsibility for the message/.
>

+1 Agreed.
-Wei


>
>
> Best
> Ale
> --
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC interop and abuse concerns

[Wei Chuang]

Apologies for repeating myself here and creating noise.  I'm just
re-walking through the thread, trying to get to Scott's subsequent
response, which I wanted to get to.
-Wei

On Sun, Mar 19, 2023 at 12:19 AM Wei Chuang  wrote:

>
>
> On Tue, Mar 14, 2023 at 9:11 AM Scott Kitterman 
> wrote:
>
>> For the replay resistance part of the question, I think it would make
>> sense to wait and see how the DKIM working group addresses the problem for
>> DKIM generally and then assess how their solution impacts ARC and how it
>> addresses the issue for ARC.
>>
>
> Agreed.
>
>
>> I think the question of spamminess is orthogonal to the authentication
>> questions that ARC attempts to answer.  It's subjective, so I don't think
>> it can really play into ARC.
>>
>
> Agreed.  I'd like to encourage folks to generate ARC headers even if the
> message is perceived to be somehow spammy.
>
>
>> Additionally, if the intermediary thinks a message is bad (spam), then
>> the solution is to not send the message onward and try to make it someone
>> else's problem.
>>
>
> Some of this is because the intermediary doesn't realize a particular
> message is spammy.  However the forwarder suspects that some forwarded mail
> might contain spam, and doesn't want to help authenticate that at all,
> hence doesn't generate ARC headers. This despite knowing it could help the
> receiver better apply DMARC policy.
>
> -Wei
>
>
>> Scott K
>>
>> On March 14, 2023 2:49:30 PM UTC, Wei Chuang > 40google@dmarc.ietf.org> wrote:
>> >Hi all,
>> >We've been making use of ARC to help with forwarded mail.  One thing
>> we've
>> >noticed is differences for when some forwarders generate the ARC headers.
>> >Another concern is that we've seen spammers attempt to manipulate ARC
>> >headers.
>> >1) ARC could benefit from more refinement of interop such as when to
>> >generate ARC headers e.g. if the message appears spammy? and how should
>> the
>> >ARC-Authentication-Results be reported if there is a local policy
>> >override?  Would it be helpful to clarify this with a BCP?
>> >2) Considerations on what to do about ARC header spoofing and replay.  I
>> >have an I-D
>> >https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/ that
>> >outlines some ideas on mitigating that (particularly the "SeRCi" idea) as
>> >one starting point.  (In case it matters I should point out the DARA idea
>> >in the draft is more oriented towards DKIM).
>> >-Wei
>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC interop and abuse concerns

[Wei Chuang]

On Tue, Mar 14, 2023 at 9:11 AM Scott Kitterman 
wrote:

> For the replay resistance part of the question, I think it would make
> sense to wait and see how the DKIM working group addresses the problem for
> DKIM generally and then assess how their solution impacts ARC and how it
> addresses the issue for ARC.
>

Agreed.


> I think the question of spamminess is orthogonal to the authentication
> questions that ARC attempts to answer.  It's subjective, so I don't think
> it can really play into ARC.
>

Agreed.  I'd like to encourage folks to generate ARC headers even if the
message is perceived to be somehow spammy.


> Additionally, if the intermediary thinks a message is bad (spam), then the
> solution is to not send the message onward and try to make it someone
> else's problem.
>

Some of this is because the intermediary doesn't realize a particular
message is spammy.  However the forwarder suspects that some forwarded mail
might contain spam, and doesn't want to help authenticate that at all,
hence doesn't generate ARC headers. This despite knowing it could help the
receiver better apply DMARC policy.

-Wei


> Scott K
>
> On March 14, 2023 2:49:30 PM UTC, Wei Chuang  40google@dmarc.ietf.org> wrote:
> >Hi all,
> >We've been making use of ARC to help with forwarded mail.  One thing we've
> >noticed is differences for when some forwarders generate the ARC headers.
> >Another concern is that we've seen spammers attempt to manipulate ARC
> >headers.
> >1) ARC could benefit from more refinement of interop such as when to
> >generate ARC headers e.g. if the message appears spammy? and how should
> the
> >ARC-Authentication-Results be reported if there is a local policy
> >override?  Would it be helpful to clarify this with a BCP?
> >2) Considerations on what to do about ARC header spoofing and replay.  I
> >have an I-D
> >https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/ that
> >outlines some ideas on mitigating that (particularly the "SeRCi" idea) as
> >one starting point.  (In case it matters I should point out the DARA idea
> >in the draft is more oriented towards DKIM).
> >-Wei
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC interop and abuse concerns

[Wei Chuang]

On Tue, Mar 14, 2023 at 9:11 AM Scott Kitterman 
wrote:

> For the replay resistance part of the question, I think it would make
> sense to wait and see how the DKIM working group addresses the problem for
> DKIM generally and then assess how their solution impacts ARC and how it
> addresses the issue for ARC.
>
> I think the question of spamminess is orthogonal to the authentication
> questions that ARC attempts to answer.  It's subjective, so I don't think
> it can really play into ARC.
>
> Additionally, if the intermediary thinks a message is bad (spam), then the
> solution is to not send the message onward and try to make it someone
> else's problem.
>

Likely the issue is that the intermediary doesn't think of the specific
message as being spam, yet is worried about the possibility of
authenticating spam so drops ARC for some scenarios. The receiver still
could benefit from seeing the Authentication-Results of the intermediary.
In other scenarios, the ARC headers are intentionally broken by a spammer.
Should non-malicious forwarders of those messages still generate ARC
headers?  Keep in mind, the forwarder again might not realize the message
is spammy

-Wei

>
> Scott K
>
> On March 14, 2023 2:49:30 PM UTC, Wei Chuang  40google@dmarc.ietf.org> wrote:
> >Hi all,
> >We've been making use of ARC to help with forwarded mail.  One thing we've
> >noticed is differences for when some forwarders generate the ARC headers.
> >Another concern is that we've seen spammers attempt to manipulate ARC
> >headers.
> >1) ARC could benefit from more refinement of interop such as when to
> >generate ARC headers e.g. if the message appears spammy? and how should
> the
> >ARC-Authentication-Results be reported if there is a local policy
> >override?  Would it be helpful to clarify this with a BCP?
> >2) Considerations on what to do about ARC header spoofing and replay.  I
> >have an I-D
> >https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/ that
> >outlines some ideas on mitigating that (particularly the "SeRCi" idea) as
> >one starting point.  (In case it matters I should point out the DARA idea
> >in the draft is more oriented towards DKIM).
> >-Wei
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] ARC interop and abuse concerns

[Wei Chuang]

Hi all,
We've been making use of ARC to help with forwarded mail.  One thing we've
noticed is differences for when some forwarders generate the ARC headers.
Another concern is that we've seen spammers attempt to manipulate ARC
headers.
1) ARC could benefit from more refinement of interop such as when to
generate ARC headers e.g. if the message appears spammy? and how should the
ARC-Authentication-Results be reported if there is a local policy
override?  Would it be helpful to clarify this with a BCP?
2) Considerations on what to do about ARC header spoofing and replay.  I
have an I-D
https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/ that
outlines some ideas on mitigating that (particularly the "SeRCi" idea) as
one starting point.  (In case it matters I should point out the DARA idea
in the draft is more oriented towards DKIM).
-Wei


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC agenda for IETF 116 -- and do we need one?

[Wei Chuang]

Potentially one area of discussion is ARC.  Two things come to mind:
1) ARC could benefit from more refinement of interop such as when to
generate ARC headers e.g. if the message appears spammy? and how should the
ARC-Authentication-Results be reported if there is a local policy override?
2) Considerations on what to do about ARC header spoofing and replay.
If it's better to start a separate thread on the list to see if there's
enough interest first, I can do that.
-Wei

On Sun, Mar 12, 2023 at 9:15 AM Barry Leiba  wrote:

> What I'm hearing so far is: "Cancel the DMARC session."
>
> I will do that on Wednesday if I don't hear a reason not to.  Please
> speak up quickly if you think cancelling is not the right thing.
>
> Barry
>
> On Thu, Mar 9, 2023 at 8:51 PM Barry Leiba 
> wrote:
> >
> > We do have a session scheduled for IETF 116.
> >
> > We do not yet have a preliminary agenda for that session.
> >
> > So:
> >
> > 1. Do we, indeed, still need that session to happen?
> >
> > 2. If so, let's collect an agenda for it.
> >
> > Document authors definitely NEED TO weigh in.  Others, please also
> > raise any issues you want to discuss, or make a case for cancelling
> > the session.
> >
> > Thanks,
> > Barry
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [PROPOSAL]: Timing data in aggregate reports

[Wei Chuang]

Which values were you thinking of reporting for the min/max/avg
statistics?  Some time delta value exceeding the "x="?  The DKIM delta
between "x=" values "t=" values?

Presumably this is to help report to the sender when their expiry value is
having trouble with some receiver/forwarder?
-Wei



On Fri, Feb 17, 2023 at 11:02 AM Alessandro Vesely  wrote:

> Hi,
>
> how to set DKIM expiration (x=) is being discussed in the DKIM WG.  Making
> educated guesses requires some data.  Aggregate reports are the right
> place for
> that.  For example:
>
>  
>  
>  192.0.2.119
>  184
>  4
>  312
>  21
>  
>  ...
>
> Min, max and avg are functions present in almost all packages that deal
> with
> collections, from DBMSes to programming languages.  So adding them is just
> a
> few minutes more than what would be needed to upgrade to the new spec as
> it is now.
>
> I aired this idea in [ietf-dkim], and I'm looking forward to seeing the
> same
> reaction here.  However, what about messages from the dmarc list for the
> week
> ending Sun Feb 19 06:00:04 2023?
>
>
> Best
> Ale
> --
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] draft-levine-dkim-conditional (was Re: Mailing List message authentication)

[Wei Chuang]

On Mon, Aug 22, 2022 at 5:43 PM John R. Levine  wrote:

> On Mon, 22 Aug 2022, Wei Chuang wrote:
> > I agree with the OP's premise that there needs to be a better
> > authentication method that works with mailing lists. ...
>
> Google seems pretty enthusiastic about ARC.
>
> Since large mail systems already know where the mailing lists are, I asked
> why not just skip DMARC checking on list mail.  The answer was that lists
> leak a lot of spam since many do very weak filtering, checking only that
> the From: address is a subscriber.  The point of ARC is to package up the
> authentication history of a message so the final recipient can
> retroactively do the filtering that the previous stages didn't.  If you
> look back at the ARC chain and see that a message was aligned when it
> arrived at a list, which is easy to do, that greatly reduces the chances
> that the message is spam.
>
> I wrote up a proposal for conditional signatures, which lets a sender put
> a weak DKIM signature on a message that is only valid if it's also signed
> by a specificed second signer, which would be the list.  The original
> signature just covers a few headers that the list is unlikely to change,
> but it lets the message continue to be DMARC aligned after a list modifies
> it.  The ARC-ists didn't like it because it requires the original sender
> to know who's going to re-sign a message, while ARC only looks backward.
>
> https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/


I like the concept of the sender specifying the forwarding path that this
proposal introduces.  That idea can provide authentication and I believe
resist replay attacks.  I think this proposal would be more powerful if
built into a framework like ARC and its ARC sets that can help it
generalize describing forwarding through arbitrary many hops.


> I don't think ARC is wonderful but I would be surprised if we could come
> up with anything better, and doubly surprised if large mail operators like
> Microsoft and Google who are already doing ARC trials would be interested.
>

I can't speak for my employer, but I think it's a good idea to come up with
something better.  The currently deployed authentication approaches DKIM
and SPF that DMARC depends upon are showing their age, and have well known
issues.  In fact those well known issues such as DKIM replay, may make the
conditions ripe for making improvements and justifying changes.

-Wei


>
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mailing List message authentication

[Wei Chuang]

On Mon, Aug 22, 2022 at 6:32 AM Barry Leiba  wrote:

> > Mailing lists are supposed to be a closed group.   This means that posts
> should only be accepted if they are verifiably
> > from the subscriber indicated in the RFC5322.From address.   This
> requirement means that a list needs a mechanism
> > for verifying the RFC5322.From address, and the mechanism needs to be
> applicable to 100% of the accepted
> > subscriber base.
>
> None of this is true in general.
>
> Some mailing lists operate so that only subscribers can post.  Many do
> not.  Even those that do generally do not insist on authentication.
> Some will use DMARC policy to determine what the purported From
> domain's policy is.  Some do not.
>
> > At present, we have only one official mechanism for verification of
> RFC5322.From, which is DMARC.  However, DMARC
> > is currently limited to domains that publish a DMARC policy, and this is
> a small subset of all potential subscriber domains.
>
> Because that's what DMARC is designed for.
>
> > DMARC actually creates a bizarre situation:
>
> DMARC does not create a bizarre situation.  Internet email is
> inherently an unauthenticated thing.  DMARC, along with authentication
> mechanisms (currently SPF and DKIM), addresses that point in the
> manner for which it was designed.  DMARC was not designed to address
> it for cases where domains have not chosen to publish DMARC policies.
>
> I believe we have been through this multiple times and that working
> group consensus is against you on it.  The working group does not want
> to extend DMARC beyond that design point.
>
> Barry
>
>
I agree with the OP's premise that there needs to be a better
authentication method that works with mailing lists.  Stating the obvious
for many, but an important contributor to the lack of DMARC adoption, is
the difficulty in supporting mailing lists and other forwarding flows that
may modify the message which affects deliverability.  Some may say that
DKIM is the right solution for forwarding flow, but message modification
breaks DKIM.  Another limitation is that DKIM is susceptible to replay
attacks that make its results suspect.  Yet at the same time DMARC provides
valuabling signaling about how to authenticate the originator which we lose
due to lack of adoption.  I agree with the OP that there should be work on
a new authentication algorithm (or significantly improving existing ones)
that DMARC can then use in its policy framework.  I'll write up some
concepts and send it out to the DKIM list (it was suggested that was a good
venue for the proposals, likely due to the charter issues mentioned here).
It will start off with DKIM replay mitigations, but hopefully work towards
better support for mailing lists.

-Wei


> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Reversing modifications from mailing lists

[Wei Chuang]

On Sat, Nov 27, 2021 at 7:34 PM Ned Freed  wrote:

> > It appears that Wei Chuang   said:
> > > If the RFC2045 canonical representation at the final destination can
> be the
> > > same as the canonical representation at the original sender, ...
>
> > When we were working on DKIM canonicalization we had lengthy discussions
> about
> > what to do about MIME and we decided not to even try.
>
> A mistake IMO.
>
> > There is no canonical
> > representation of a MIME message and nobody to my knowledge has ever
> tried to
> > describe what it would mean for two MIME messages to be equivalent,
> since they
> > could vary in a fantastic number of ways.
>
> First, a caonnical form doesn't have to produce a 100% reliable equivalency
> test in order to be useful.
>
> Second, there can be more to a hash computation than a canonical form. This
> is especially true given that a MIME message is a tree.
>
> > Part separators can change, the
> > pieces of multipart/whatever might change, line breaks in
> quoted-printable
> > and base64 can change, spacing and capitalization of headers can change,
> and
> > that's just what I can think of in two minutes.
>
> If you treat the message as a Merkle tree with:
>
> o Separate header and body hashes
> o Decoding message bodies prior to hashing
> o Applying the already-defined unfolding/capitalization stuff from DKIM
>   to part headers.
> o Removing the CTE field and boundary value from CT fields in the header
>
> You end up with a value that's:
>
> o Invariant in regards to part separator changes
> o Invariant in regards to CTE changes
> o Invariant in regards to many/most common header changes
> o Allows for rapid computation of hashes for large numbers of large
> messages
>   that share common content.
>
> Which I note takes care of your list.
>

This approach and benefit was what I was thinking could be feasible as
well.  The cited draft-kucherawy-dkim-list-canon
<https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-list-canon>
draft notes
your contribution to the concept described there i.e. to perform hashing as
a mime-tree (though that draft doesn't do content transport decoding).


> But the question is, as always, whether or not defining such a thing is
> worth
> the trouble. At this point I think the answer is "no".
>

What type of concern do you have?  Is it algorithmic complexity?  Or
runtime or header size overhead?

-Wei
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] UNCOL and Reversing modifications from mailing lists

[Wei Chuang]

On Tue, Nov 23, 2021 at 12:34 PM John Levine  wrote:

> It appears that Wei Chuang   said:
> >I saw Ale's draft draft-vesely-dmarc-mlm-transform
> ><https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform>
> in
> >the ARC list, and wanted to discuss some of the ideas. ...
>
> Please humor me for a moment while I turn the clock way back to 1958.
>
> Fortran and Cobol had shown that compilers worked, and people were busy
> writing compilers for lots of languages for lots of computers.  But that
> was a daunting amount of work, N languages for M computers is NxM
> compilers.
>
> Mel Conway, best known for the law "Organizations, who design
> systems, are constrained to produce designs which are copies of the
> communication structures of these organizations", published a paper
> proposing a Universal Computer Oriented Language or UNCOL.  The front
> end of each compiler would translate from Fortran or whatever to UNCOL,
> and the back ends would translate from UNCOL to IBM 7070 machine code
> or whatever, reducing the work from NxM to N+M.
>
> Work started with great enthusiasm in the early 1960s, and people
> produced UNCOLs that could handle one or two input languages, and one
> or two output machine codes, and reported great success. But they
> found that every new input language or output machine required more
> and more special cases which swamped whatever was supposed to be
> common, and UNCOL experienced heat death, was quietly shelved and
> forgotten.
>
> The Open Software Foundation had an ANDF, Architecture Neutral
> Distribution Format around 1989.  They were very offended when I said it
> sounded just like UNCOL, but it died the same way.
>
> This proposal is UNCOL for mailing lists. Can you come up with a demo
> that handles a few common changes that Mailman makes? Sure. How about
> if you add the slightly different changes that Sympa makes? Probably.
> What about LISTSERV and phpList and ezmlm and listproc and groups.io
> and Google Groups and Yahoo Groups and body headers and MIME footers
> and all the other things that mailing lists do?  Maybe not.
>

Understood there is a lot of complexity in this space.  On the other hand
there doesn't seem to be a complete solution to email authentication with
regard to content modification by email forwarders.  The result is that
DMARC adoption is low despite its benefit in preventing important classes
of email impersonation.  I guess it makes sense that a lot of these are
experimental, and that hopefully one of these will emerge to be the best,
and thereby make the other techniques redundant, and clean up some of the
complexity.


>
> Uh, perhaps we could focus on how to get ARC more widely adopted,
> since it has the advantage of not making any unrealistic assumptions
> about what changes lists might make.
>

There ought to be a thread trying to figure out why that is.  (FWIW as
mentioned in the other thread, IMO there are places where ARC makes more
sense to use, hence should figure this out)
-Wei


>
> R's,
> John
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Reversing modifications from mailing lists

[Wei Chuang]

Thanks for the feedback and answers.

On Wed, Nov 24, 2021 at 3:01 AM Alessandro Vesely  wrote:

> Hi,
>
> On Tue 23/Nov/2021 00:28:01 +0100 Wei Chuang wrote:
> >
> > 1. Ale's draft suggests not reversing all possible transforms, and
> rather
> > focuses on a subset caused by mailing lists that are reversible
> >* Could ARC be suitable for those other scenarios? Could we expect
> that
> > forwarders that do more substantial irreversible rewriting such as
> modifying
> > URLs in a spam/phishing filter MTA, already have a strong relationship
> with the
> > receiver?  Presumably, might they be trusted by the receiver and their
> ARC
> > result could be used?
>
>
> Sure.  Note that if the receiver trusts the MLM, simply recognizing it
> would be
> enough to pass DMARC per the "mailing_list" policy override.  ARC
> additionally
> provides the ability to learn the authentication status of the message
> when it
> was received by the MLM.  That way, reputation can be reckoned with great
> precision.
>
>
> > 2. Footers must only be added with as a) append on single text/plain
> part b)
> > mime part appended to multipart/mixed c) mime wrap where a footer is
> added in a
> > new multipart/mixed.
> >* It's not very clear to me how Ale's draft handles the b) and c)
> scenario.
> >   (There is mention of "reason="transformed"", but this still seems
> incomplete)
> >   I saw that Murray has a draft draft-kucherawy-dkim-list-canon
> > <https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-list-canon> that
>
> > identifies addition of new mime parts that could be helpful there.
>
>
> I tried and implemented Murray's draft, but it requires that MLMs declare
> which
> transformation they do.  Since they don't, you need a pre-parser that
> guesses
> the transformation type.  That's the difference between the two drafts.
>
> If there are two top-level MIME parts, the transformation must be (c),
> because
> no one writes a MIME structure with just one part.  Otherwise it's (b).
>
>
> > 3.  Footers added to text/plain must be identified with at least four
> "_" as a
> > separator.
> >* Would the DKIM length "l=" field be helpful?  Understood there are
> abuse
> > risks.
>
>
> Yes, l= could be a useful hint.
>
> The risk of l= is that an attacker could exploit a poor HTML interpreter
> to add
> a part that completely hides the original content when rendered.
> Requiring
> attachments to be plain text avoids that risk.
>
>
> > 4. "quoted-printable encoding must not be used for... single-part
> text/plain
> > messages, as it is impossible to guess original soft line breaks after
> re-encoding"
> > * Are you suggesting quoted printable encoding aren't fully
> reversible?
> > Actually, could the RFC2045 canonical encoding of the message be used as
> the
> > source for doing the DKIM content hashing?  This would bypass having to
> worry
> > about additional transfer re-encodings by forwarders.
>
>
> Mailman can copy MIME structures without changes, but simple text is often
> re-encoded.  Many messages on this list are converted to base64.  If the
> original text was quoted printable, its form depends on the agent.  An
> agent
> can choose where to break lines, whether to encode some characters or
> represent
> them as ASCII, whether to break lines at column 76 or, to increase
> readability,
> at white spaces.  That can vary too widely.
>

If the RFC2045 canonical representation at the final destination can be the
same as the canonical representation at the original sender, (and assuming
there isn't some content modification like adding inline footers etc). then
that might be a way of side stepping some of the issues with quoted
printable encoding.  Understood that would be a departure from DKIM/ARC
hashing and verification.


>
> > 5. Finding the original FROM by looking at From, Author, Original-From,
> > X-Original-From, Reply-To, and Cc.
> >* Can this be standardized to a fixed location such as Author?
> (Sorry I'm
> > unfamiliar with the discussion on Author)
>
>
> That's exactly the purpose of Author.  However, no one is using it yet.
>
>
> > 6. Subject
> >* Agreed that some simple heuristic as proposed in the draft is a
> good
> > approach.  Perhaps the original subject suffix length also might work
> here too.
>
>
> I don't get this, I'm afraid.  What is the subject suffix length?
>

Sorry I wasn't too clear here.  It's la

Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)

[Wei Chuang]

ni


On Wed, Dec 31, 2014, 8:36 PM Murray S. Kucherawy 
wrote:

> On Mon, Dec 29, 2014 at 2:29 PM, Rolf E. Sonneveld <
> r.e.sonnev...@sonnection.nl> wrote:
>
>>
>>
>> 3.1.3 Flow diagram
>>>
>>> The box titled 'User Mailbox' could give the impression that there's
>>> only one choice for delivery. However, quarantining can be done without
>>> delivery to a mailbox. I'd suggest to label this box 'rMDA'.
>>>
>> That's already done in -08.
>>
>>
>> OK. Well, it's MDA, but that's OK. One typo in the diagram. When:
>>
>>  "sMTA" is the sending
>>MTA, and "rMTA" is the receiving MTA.
>>
>>
>> is correct, the box in the diagram should be labelled 'sMTA', not 'oMTA'.
>>
>
> Fixed.
>
>
>>
>>
>>
>>>   The part within parentheses of step 6:
>>>
>>>   6. Recipient transport service conducts SPF and DKIM authentication
>>> checks by passing the necessary data to their respective modules, each of
>>> which require queries to the Author Domain's DNS data (when identifiers are
>>> aligned; see below).
>>>
>>>
>>> might indicate that SPF and DKIM authentication checks need not be
>>> performed when identifiers are not aligned. However, for sake of reporting,
>>> SPF and DKIM authentication checks will in general always be done, or am I
>>> missing something?
>>>
>>
>>  I can envision a DMARC implementation that skips SPF or DKIM checks if
>> the corresponding identifiers are not aligned, because they won't be
>> interesting to DMARC in that case.
>>
>>
>> Whether or not to generate reports in the case of non-alignment is not
>> clear from the text, or am I missing something? Par. 3.1.3:
>>
>> 8.  If a policy is found, it is combined with the Author's domain and
>>the SPF and DKIM results to produce a DMARC policy result (a
>>"pass" or "fail"), and can optionally cause one of two kinds of
>>reports to be generated (not shown).
>>
>>
>> and par. 6.2 goes right into the format of reports, not the conditions
>> under which a report is to be sent.
>>
>
> Added an item at the end of the bullet list in 3.1.3.
>
>
>
>>
>>
>>
>>
>>5.7 Last sentence:
>>>
>>> Mail Receivers SHOULD also implement reporting instructions of DMARC in
>>> place of any extensions to SPF or DKIM that might enable such reporting.
>>>
>>> Not sure what this means. But it seems to me DMARC cannot claim priority
>>> over other options/extensions in other IETF protocols.
>>>
>> This is another spot where the SHOULD gives the operator the choice to do
>> both if it wishes.  I can't remember off the top of my head what the use
>> case is here, but essentially the absence of a request for DKIM or SPF
>> reporting (as developed by the MARF working group some time ago) should not
>> preclude DMARC reporting, nor should their presence interfere with DMARC
>> reporting.
>>
>>
>> Then, borrowing from your text, may I suggest the following text:
>>
>> "Mail Receivers SHOULD implement reporting instructions of DMARC, even in
>> the absence of a request for DKIM or SPF reporting [MARF]. Furthermore, the
>> presence of such requests SHOULD NOT interfere with DMARC reporting."
>>
>>
> Done, with slight changes.
>
>>
>> And as a general statement: thanks for all the work, Murray!
>>
>
> Anything to get this thing put to bed!
>
> -MSK
>
> ___
> 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