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

[Jesse Thompson]

On Tue, Jul 11, 2023, at 7:49 PM, Wei Chuang wrote:
> 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

To the last item. We (as an ESP) only send with relaxed SPF alignment. Therefor 
our SPF include should [ideally] not be on the RFC5322.From domain (granted, I 
am working on revising some docs that still rely on PRA assumptions).

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

I think that with relaxed alignment it requires that a potential spoofer 
(through our service) to be able to produce an SPF aligned result that is a 
subdomain of the RFC5322.From domain (which I don't think is happening with the 
SPF upgrade attacks today, at least for us) and the spoofer would need to be 
able to know and use the same subdomain (which includes our SPF) that has a 
high reputation in your trust models. I do have concerns about penalizing 
shared IPs in general, since they are a necessity with IPv4.

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

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

[Jesse Thompson]

On Sat, Aug 5, 2023, at 11:49 AM, Dave Crocker wrote:
> On 8/5/2023 9:30 AM, Jesse Thompson wrote:
> > Governance seems like the best word to me, since Governance is what 
> > Reporting has provided to ADs in Monitoring Mode, but I do not want to 
> > say DMARG out loud either :-)
> 
> Here, too, the domain owner does not govern the platform receiver.

I don't disagree with you. My point was that the reports, provided by the 
receivers, give to the security&compliance team the provisions they need to 
convince/coerce employees to adhere to their intended governance model, 
regardless of whether the receivers honor the governance model. i.e. Monitoring 
Mode is not an exercise done in a vacuum. The reason to monitor is to achieve 
local compliance; to govern your mail streams.

p=quarantine pct=0 (now in DMARCbis: t=y) is useful to determine the extent to 
which people are participating in mailing lists and to identify lists that are 
not compensating for the interoperability issues. Without t=y, the people in 
charge of governance may just assume [incorrectly] that one or the other 
situation is rare. Sadly, I think the t=y benefit will be overlooked, because 
S&C people don't really care if the organization's employees can't easily 
participate in mailing lists. They may hope/assume that receivers will honor 
the policy, so "testing" implies "governance objective not yet complete".

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

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

[Dave Crocker]

On 8/5/2023 5:06 PM, Tim Wicinski wrote:
The former resonates with harried admins, while the later is useful 
to implementers. 


Providing a definition that is at odds with established meaning for a 
word is something that can work tech geeks but is counter-productive 
when applied for others.


d/

--
Dave Crocker
dcroc...@gmail.com
mast:@dcrocker@mastodon.social
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

[Tim Wicinski]

On Sat, Aug 5, 2023 at 7:38 PM Dave Crocker  wrote:

> On 8/5/2023 4:23 PM, Neil wrote:
>
>  Also, we understand who our audiences are in reality. Sometimes it’ll be
> a harried admin skimming the RFC, and others will take the time to do a
> deep dive. Even the harried admin scanning today might want to dive deep
> when he has more time. So out of respect for those who want to get things
> done and solve problems quickly and those who wish to grok the new DMARC
> spec, I think the optimal solution would be to follow E.B. White, making
> every word count, having empathy for the reader, and avoiding distractions
> that could bog the stressed reader down.
>
> When writing specifications, yes, it is good to consider the casual or
> harried reader.  To that end, vocabulary should not mislead.  'Policy'
> misleads about the effect of choosing a particular value.
>

The other thing I've found that has proven useful in DNS RFCs, and that
I've received positive feedback outside of IETF is when we can summarize
definitions or guidance with tables.  Two stand out - the table at the
bottom of page 25 in RFC8499 showing examples of zone delegation types:

https://datatracker.ietf.org/doc/html/rfc8499#page-25

and the table in RFC8624 listing implementation recommendations for DNSSEC
algorithms

https://datatracker.ietf.org/doc/html/rfc8624#section-3.1

The former resonates with harried admins, while the later is useful
to implementers.

I am not saying we must do this, or we can, but it's something to
consider.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

[Scott Kitterman]

On Saturday, August 5, 2023 7:38:21 PM EDT Dave Crocker wrote:
> On 8/5/2023 4:23 PM, Neil wrote:
> > > The language used for DMARC has always been problematic. "Policy"
> > > 
> > > implies control, but the domain owner has no control over the receiving
> > > platform.  Quarantine and Reject declare control that also does not
> > 
> > exist.
> > 
> > Suppose you set a policy of p=reject that’s still your policy even if
> > receivers aren’t obligated to honor your policy. But it’s a policy
> > nonetheless. It’s not required that a policy be followed for it to be
> > policy. That aside, there’s unlikely to be another word that works
> > better than’s worth any confusion or disruption that could be caused
> > by changing the jargon.
> 
> www.dictionary.com
> 
> Policy Definition & Meaning | Dictionary.com <#>
> 
> Policy definition, a definite course of action adopted for the sake of
> expediency, facility, etc.: We have a new company policy. See more.
> 
> 🔗 https://www.dictionary.com/browse/policy
> 
> 
> >  Also, we understand who our audiences are in reality. Sometimes it’ll
> > be a harried admin skimming the RFC, and others will take the time to
> > do a deep dive. Even the harried admin scanning today might want to
> > dive deep when he has more time. So out of respect for those who want
> > to get things done and solve problems quickly and those who wish to
> > grok the new DMARC spec, I think the optimal solution would be to
> > follow E.B. White, making every word count, having empathy for the
> > reader, and avoiding distractions that could bog the stressed reader down.
> 
> When writing specifications, yes, it is good to consider the casual or
> harried reader.  To that end, vocabulary should not mislead.  'Policy'
> misleads about the effect of choosing a particular value.

And part of that relates to existing usage.  Policy has been used in this way 
for 20 years (SPF after it was renamed, ADSP, and now DMARC).  I think it's 
fine in any case.  A company's policy is what they want employees to do.  
There's no guarantee they will.

Scott K


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

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

[Dave Crocker]

On 8/5/2023 4:23 PM, Neil wrote:

> The language used for DMARC has always been problematic. "Policy"

> implies control, but the domain owner has no control over the receiving
> platform.  Quarantine and Reject declare control that also does not 
exist.


Suppose you set a policy of p=reject that’s still your policy even if 
receivers aren’t obligated to honor your policy. But it’s a policy 
nonetheless. It’s not required that a policy be followed for it to be 
policy. That aside, there’s unlikely to be another word that works 
better than’s worth any confusion or disruption that could be caused 
by changing the jargon.



www.dictionary.com

Policy Definition & Meaning | Dictionary.com <#>

Policy definition, a definite course of action adopted for the sake of 
expediency, facility, etc.: We have a new company policy. See more.


🔗 https://www.dictionary.com/browse/policy 



 Also, we understand who our audiences are in reality. Sometimes it’ll 
be a harried admin skimming the RFC, and others will take the time to 
do a deep dive. Even the harried admin scanning today might want to 
dive deep when he has more time. So out of respect for those who want 
to get things done and solve problems quickly and those who wish to 
grok the new DMARC spec, I think the optimal solution would be to 
follow E.B. White, making every word count, having empathy for the 
reader, and avoiding distractions that could bog the stressed reader down.


When writing specifications, yes, it is good to consider the casual or 
harried reader.  To that end, vocabulary should not mislead.  'Policy' 
misleads about the effect of choosing a particular value.



d/

--
Dave Crocker
dcroc...@gmail.com
mast:@dcrocker@mastodon.social
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

[Neil]

From: Dave Crocker 
Date: Saturday, August 5, 2023 at 9:49 AM
To: Jesse Thompson , Neil 
Cc: Todd Herr , IETF DMARC WG 
Subject: Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

> The language used for DMARC has always been problematic. "Policy"
> implies control, but the domain owner has no control over the receiving
> platform.  Quarantine and Reject declare control that also does not exist.
Suppose you set a policy of p=reject that’s still your policy even if receivers 
aren’t obligated to honor your policy. But it’s a policy nonetheless. It’s not 
required that a policy be followed for it to be policy. That aside, there’s 
unlikely to be another word that works better than’s worth any confusion or 
disruption that could be caused by changing the jargon.

Also, we understand who our audiences are in reality. Sometimes it’ll be a 
harried admin skimming the RFC, and others will take the time to do a deep 
dive. Even the harried admin scanning today might want to dive deep when he has 
more time. So out of respect for those who want to get things done and solve 
problems quickly and those who wish to grok the new DMARC spec, I think the 
optimal solution would be to follow E.B. White, making every word count, having 
empathy for the reader, and avoiding distractions that could bog the stressed 
reader down.

Then there would be well-organized appendixes that satisfy the reader in a 
lower stress state who wants to spend some time to grok.
So I get straight to the point, postpone in-depth exploration a few pages, 
putting enough material in well-organized appendices to satisfy the desire of 
many technical people who don’t feel comfortable until they grok something. 
That can be me on the same day easily.
Thanks.
Neil


> Governance seems like the best word to me, since Governance is what
> Reporting has provided to ADs in Monitoring Mode, but I do not want to
> say DMARG out loud either :-)

Here, too, the domain owner does not govern the platform receiver.

d/

--
Dave Crocker
dcroc...@gmail.com
mast:@dcrocker@mastodon.social
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
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

[Tim Wicinski]

That is more accurate Scott.

Also I removed an extra sentence on comma-separated.

Updated https://gist.github.com/moonshiner/70377e69d482e7bf3a927d5ac468babb


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.


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



5.4.  Formal Definition



dmarc-method = "dkim" / "spf"


dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method)



I did not word smith Wei's 4.3 text.

On Sat, Aug 5, 2023 at 6:17 PM Scott Kitterman  wrote:

> On Saturday, August 5, 2023 6:11:03 PM EDT Tim Wicinski wrote:
> > On Sat, Aug 5, 2023 at 6:00 PM Scott Kitterman 
> wrote:
> > > On August 5, 2023 9:51:54 PM UTC, Tim Wicinski 
> wrote:
> > > >On Sat, Aug 5, 2023 at 5:35 PM John Levine  wrote:
> > > >> According to Tim Wicinski  :
> > > >> >-=-=-=-=-=-
> > > >> >
> > > >> >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)
> > > >
> > > >1) I realize we may need someway to update the dmarc-method if a new
> one
> > >
> > > is
> > >
> > > >added (okay okay)
> > > >
> > > >> That looks OK, with large clear text saying that if any of the
> listed
> > > >> methods pass, it's aligned.
> > > >
> > > >2) I missed Scott's comment the default should be "spf,dkim"
> > > >
> > > >I wordsmithed Wei's definition  above for Section 5.3
> > > >
> > > >  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> > > >
> > > >default is "spf,dkim")
> > > >
> > > >Indicates the supported authentication methods. If more than one
> > >
> > > method
> > >
> > > >is specified,
> > > >
> > > >they are comma ',' separated without whitespace.  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 no authentication method is specified and
> > >
> > > DMARC
> > >
> > > >is disabled.
> > > >
> > > >If any listed method passes, then DMARC is aligned.
> > > >
> > > >Should I do a pull request etc, etc?
> >
> > Scott
> >
> > I'd prefer an empty list means the tag is ignored.  I don't see a use
> case
> >
> > > for publishing a record that means DMARC is disabled.  Also, I think
> it's
> > > confusing.  I would find it more natural to mean no auth methods are
> used
> > > (i.e. everything fails), not DMARC is disabled.  The canonical method
> for
> > > disabiling DMARC is to not publish a record.  I don't think we need
> > > another
> > > way to express the same thing in a less clear way.
> >
> > Agreed.
> >
> >   auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> > default is "spf,dkim")
> > Indicates the supported authentication methods. If more than one
> method
> > is specified,
> > they are comma ',' separated without whitespace.  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.
> >
> > If any listed method passes, then DMARC is aligned.
> >
> > https://gist.github.com/moonshiner/70377e69d482e7bf3a927d5ac468babb
> >
> >
> > also " I don't think we need another way to express the same thing in a
> > less clear way."
> >
> > +eleventy billion
>
> I missed this before ...
>
> Shouldn't "If any listed method passes, then DMARC is aligned." be "If any
> listed method passes and is aligned, then DMARC passes."?
>
> 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

[Scott Kitterman]

On Saturday, August 5, 2023 6:11:03 PM EDT Tim Wicinski wrote:
> On Sat, Aug 5, 2023 at 6:00 PM Scott Kitterman  wrote:
> > On August 5, 2023 9:51:54 PM UTC, Tim Wicinski  wrote:
> > >On Sat, Aug 5, 2023 at 5:35 PM John Levine  wrote:
> > >> According to Tim Wicinski  :
> > >> >-=-=-=-=-=-
> > >> >
> > >> >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)
> > >
> > >1) I realize we may need someway to update the dmarc-method if a new one
> > 
> > is
> > 
> > >added (okay okay)
> > >
> > >> That looks OK, with large clear text saying that if any of the listed
> > >> methods pass, it's aligned.
> > >
> > >2) I missed Scott's comment the default should be "spf,dkim"
> > >
> > >I wordsmithed Wei's definition  above for Section 5.3
> > >
> > >  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> > >
> > >default is "spf,dkim")
> > >
> > >Indicates the supported authentication methods. If more than one
> > 
> > method
> > 
> > >is specified,
> > >
> > >they are comma ',' separated without whitespace.  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 no authentication method is specified and
> > 
> > DMARC
> > 
> > >is disabled.
> > >
> > >If any listed method passes, then DMARC is aligned.
> > >
> > >Should I do a pull request etc, etc?
> 
> Scott
> 
> I'd prefer an empty list means the tag is ignored.  I don't see a use case
> 
> > for publishing a record that means DMARC is disabled.  Also, I think it's
> > confusing.  I would find it more natural to mean no auth methods are used
> > (i.e. everything fails), not DMARC is disabled.  The canonical method for
> > disabiling DMARC is to not publish a record.  I don't think we need
> > another
> > way to express the same thing in a less clear way.
> 
> Agreed.
> 
>   auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> default is "spf,dkim")
> Indicates the supported authentication methods. If more than one method
> is specified,
> they are comma ',' separated without whitespace.  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.
> 
> If any listed method passes, then DMARC is aligned.
> 
> https://gist.github.com/moonshiner/70377e69d482e7bf3a927d5ac468babb
> 
> 
> also " I don't think we need another way to express the same thing in a
> less clear way."
> 
> +eleventy billion

I missed this before ...

Shouldn't "If any listed method passes, then DMARC is aligned." be "If any 
listed method passes and is aligned, then DMARC passes."?

Scott K


___
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

[Tim Wicinski]

On Sat, Aug 5, 2023 at 6:00 PM Scott Kitterman  wrote:

>
>
> On August 5, 2023 9:51:54 PM UTC, Tim Wicinski  wrote:
> >On Sat, Aug 5, 2023 at 5:35 PM John Levine  wrote:
> >
> >> According to Tim Wicinski  :
> >> >-=-=-=-=-=-
> >> >
> >> >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)
> >>
> >>
> >1) I realize we may need someway to update the dmarc-method if a new one
> is
> >added (okay okay)
> >
> >
> >
> >
> >> That looks OK, with large clear text saying that if any of the listed
> >> methods pass, it's aligned.
> >>
> >
> >2) I missed Scott's comment the default should be "spf,dkim"
> >
> >I wordsmithed Wei's definition  above for Section 5.3
> >
> >  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
> >default is "spf,dkim")
> >Indicates the supported authentication methods. If more than one
> method
> >is specified,
> >they are comma ',' separated without whitespace.  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 no authentication method is specified and
> DMARC
> >is disabled.
> >
> >If any listed method passes, then DMARC is aligned.
> >
> >Should I do a pull request etc, etc?
>
>
Scott

I'd prefer an empty list means the tag is ignored.  I don't see a use case
> for publishing a record that means DMARC is disabled.  Also, I think it's
> confusing.  I would find it more natural to mean no auth methods are used
> (i.e. everything fails), not DMARC is disabled.  The canonical method for
> disabiling DMARC is to not publish a record.  I don't think we need another
> way to express the same thing in a less clear way.
>
>
Agreed.

  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
default is "spf,dkim")
Indicates the supported authentication methods. If more than one method
is specified,
they are comma ',' separated without whitespace.  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.

If any listed method passes, then DMARC is aligned.

https://gist.github.com/moonshiner/70377e69d482e7bf3a927d5ac468babb


also " I don't think we need another way to express the same thing in a
less clear way."

+eleventy billion

tim



> 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

[Scott Kitterman]

On August 5, 2023 9:51:54 PM UTC, Tim Wicinski  wrote:
>On Sat, Aug 5, 2023 at 5:35 PM John Levine  wrote:
>
>> According to Tim Wicinski  :
>> >-=-=-=-=-=-
>> >
>> >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)
>>
>>
>1) I realize we may need someway to update the dmarc-method if a new one is
>added (okay okay)
>
>
>
>
>> That looks OK, with large clear text saying that if any of the listed
>> methods pass, it's aligned.
>>
>
>2) I missed Scott's comment the default should be "spf,dkim"
>
>I wordsmithed Wei's definition  above for Section 5.3
>
>  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
>default is "spf,dkim")
>Indicates the supported authentication methods. If more than one method
>is specified,
>they are comma ',' separated without whitespace.  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 no authentication method is specified and DMARC
>is disabled.
>
>If any listed method passes, then DMARC is aligned.
>
>Should I do a pull request etc, etc?

I'd prefer an empty list means the tag is ignored.  I don't see a use case for 
publishing a record that means DMARC is disabled.  Also, I think it's 
confusing.  I would find it more natural to mean no auth methods are used (i.e. 
everything fails), not DMARC is disabled.  The canonical method for disabiling 
DMARC is to not publish a record.  I don't think we need another way to express 
the same thing in a less clear way.

Scott K

___
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

[Tim Wicinski]

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

> According to Tim Wicinski  :
> >-=-=-=-=-=-
> >
> >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)
>
>
1) I realize we may need someway to update the dmarc-method if a new one is
added (okay okay)




> That looks OK, with large clear text saying that if any of the listed
> methods pass, it's aligned.
>

2) I missed Scott's comment the default should be "spf,dkim"

I wordsmithed Wei's definition  above for Section 5.3

  auth:  (comma-separated plain-text list of dmarc-methods; OPTIONAL;
default is "spf,dkim")
Indicates the supported authentication methods. If more than one method
is specified,
they are comma ',' separated without whitespace.  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 no authentication method is specified and DMARC
is disabled.

If any listed method passes, then DMARC is aligned.

Should I do a pull request etc, etc?

tim



> R's,
> John
> --
> 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
>
> ___
> 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

[Scott Kitterman]

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.

Scott K


___
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

[John Levine]

According to Tim Wicinski  :
>-=-=-=-=-=-
>
>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)

That looks OK, with large clear text saying that if any of the listed
methods pass, it's aligned.

R's,
John
-- 
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

___
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

[Tim Wicinski]

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.

tim

* no doubt I missed something and looked to be schooled

On Sat, Aug 5, 2023 at 12:06 PM Barry Leiba  wrote:

> Two things:
>
> > If unspecified with a policy tag "auth=",  this indicates that both DKIM
> and SPF are supported.
>
> I don’t like this approach.  I think that the absence of auth= means what
> it has always meant: the sending domain is not specifying what
> authentication methods it is using and the receiving domain should check
> both SPF and DKIM.
>
> This is significantly different to the sending domain explicitly
> specifying that it uses DKIM in that in the latter case the receiving
> domain can treat the absence of a DKIM signature with suspicion.
>
> And the ABNF is needlessly complex and does not allow for extension.  It’s
> easy to rework it in the manner of many other specifications that do
> similar things.
>
> Barry
>
>
> On Fri, Aug 4, 2023 at 12:17 PM Wei Chuang  40google@dmarc.ietf.org> wrote:
>
>> 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 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

[John Levine]

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.

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

R's,
John

___
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

[John Levine]

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.

R's,
John

___
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

[Tim Wicinski]

On Fri, Aug 4, 2023 at 5: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. I would also suggest breaking up the paragraph to perhaps spell
these out more clearly:


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.


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

I don't see upgrade and downgrade elsewhere in the -28 version, so I would
agree


> 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.
>
> 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] Idle Musings - Why Is It DMARC and not DMARD?

[Hector Santos]

On Aug 5, 2023, at 12:57 PM, Benny Pedersen  wrote:
> 
> Dave Crocker skrev den 2023-08-05 18:49:
> 
>>> Governance seems like the best word to me, since Governance is what 
>>> Reporting has provided to ADs in Monitoring Mode, but I do not want to say 
>>> DMARG out loud either :-)
>> Here, too, the domain owner does not govern the platform receiver.
> 
> good news for paypal phishers, sadly
> 
> the recipient should newer recieve mail that is with credit card info by 
> dmarc is unaligned to the dmarc policy, when policy is basicly ignored we 
> have the underlaying problem dmarc should solve, but as is does not
> 

As a receiver,  I don’t wish to be inundated with spam or spoofs. I will honor 
incoming mail domain policies with deterministic rules.  As a sender, I want 
other receivers to also honor and protect my domains as well.  It’s a win-win. 

SPF -ALL has proved to help with an average of ~5% rejects since its 
introduction.  The growth was slow and it has come with its irritating small 
amount of well-known forwarding problems.  With DMARC, we just have not enabled 
p=reject failures yet.  We need more persistent deterministic DMARC “rules” 
before flipping this switch.

SPF and DKIM Policy models since SSP has been about informing receivers about 
Domain Mail Operational expectations.  This has been good. Receiver Local 
Policy always prevails but a “hint” can help decide things especially when it 
comes to failures.   

—
HLS



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

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

[Benny Pedersen]

Dave Crocker skrev den 2023-08-05 18:49:

Governance seems like the best word to me, since Governance is what 
Reporting has provided to ADs in Monitoring Mode, but I do not want to 
say DMARG out loud either :-)

Here, too, the domain owner does not govern the platform receiver.


good news for paypal phishers, sadly

the recipient should newer recieve mail that is with credit card info by 
dmarc is unaligned to the dmarc policy, when policy is basicly ignored 
we have the underlaying problem dmarc should solve, but as is does not


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

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

[Dave Crocker]

On 8/5/2023 9:30 AM, Jesse Thompson wrote:


Conformance has a synonym Compliance, which may be a reason why people 
in the ranks of Security and Compliance in "general purpose" Author 
Domains fixate on p=quarantine|reject as a rubric to assess their 
perceived security posture without any serious knowledge/consideration 
of the email interoperability issues, and then inevitably there's some 
kind of unsolvable security incident that convinces the CISO to say 
"damn the torpedoes".


The language used for DMARC has always been problematic. "Policy" 
implies control, but the domain owner has no control over the receiving 
platform.  Quarantine and Reject declare control that also does not exist.



Governance seems like the best word to me, since Governance is what 
Reporting has provided to ADs in Monitoring Mode, but I do not want to 
say DMARG out loud either :-)


Here, too, the domain owner does not govern the platform receiver.

d/

--
Dave Crocker
dcroc...@gmail.com
mast:@dcrocker@mastodon.social
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

[Jesse Thompson]

On Sun, Jul 23, 2023, at 4:38 PM, Neil Anuskiewicz wrote:
> > On Jun 30, 2023, at 11:33 AM, Dave Crocker  wrote:
> > > On 6/30/2023 11:22 AM, Todd Herr wrote:
> >> Why is the mechanism called "Domain-based Message Authentication, 
> >> Reporting, and Conformance" and not "Domain-based Message Authentication, 
> >> Reporting, and Disposition"?
> > 
> > Say DMARC out loud.  Now say DMARD out loud.
> 
> I like the way you think, Mr. Crocker. What a difference a letter makes. 
> Dmarc sounds important, serious. DMARD sounds like something a high college 
> friend might have made up to describe something stupid. 

It also phonetically sounds like an abbreviation of Demarcation, which make it, 
what, a double entendre?

Conformance has a synonym Compliance, which may be a reason why people in the 
ranks of Security and Compliance in "general purpose" Author Domains fixate on 
p=quarantine|reject as a rubric to assess their perceived security posture 
without any serious knowledge/consideration of the email interoperability 
issues, and then inevitably there's some kind of unsolvable security incident 
that convinces the CISO to say "damn the torpedoes".

Governance seems like the best word to me, since Governance is what Reporting 
has provided to ADs in Monitoring Mode, but I do not want to say DMARG out loud 
either :-)

Jesse___
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

[Barry Leiba]

Two things:

> If unspecified with a policy tag "auth=",  this indicates that both DKIM
and SPF are supported.

I don’t like this approach.  I think that the absence of auth= means what
it has always meant: the sending domain is not specifying what
authentication methods it is using and the receiving domain should check
both SPF and DKIM.

This is significantly different to the sending domain explicitly specifying
that it uses DKIM in that in the latter case the receiving domain can treat
the absence of a DKIM signature with suspicion.

And the ABNF is needlessly complex and does not allow for extension.  It’s
easy to rework it in the manner of many other specifications that do
similar things.

Barry


On Fri, Aug 4, 2023 at 12:17 PM Wei Chuang  wrote:

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

[Alessandro Vesely]

On Fri 04/Aug/2023 21:14:18 + Scott Kitterman wrote:

On August 4, 2023 4:16:39 PM UTC, Wei Chuang 
 wrote:

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"



I'd drop the requirements of not having whitespace.  If we opt for a 
colon-separated list, why not stick with DKIM's sig-h-tag syntax?  That is:


dmarc-auth = %s"auth" equals *WSP [dmarc-method]
  *( *WSP ":" *WSP dmarc-method )

dmarc-method = %s"dkim" / %s"spf"



Table:
Tag Name   Value Rule
auth dmarc-auth


I'm still not convinced we need this, but I can live with it.



We need it after the often-cited paper showing how to reliably obtain 
spf=pass using current free-mailbox providers.  With the current spec, that 
sloppy SPF settings translates to dmarc=pass, with no possibility to amend it.




In 5.3 you need to specify the tag is optional and that the default (to be used 
in the absence of the tag) is spf:dkim.  That is necessary to preserve backward 
compatibility with existing records (which I think is essential for DMARCbis).



BTW, Section 5.4 seems to be missing a number of %s'.


Best
Ale
--








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