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

[Hector Santos]

A small follow up about my DMARC view:

> On Jun 30, 2023, at 4:02 PM, Hector Santos 
>  wrote:
> 
> Overall, imo, it is never a good idea to exerted changes on domains with bis 
> specs, requiring them to change their current DMARC record to reinforce the 
> security level they want using SPF in DMARC evaluation. 
> 


I don’t want surprises. Higher support cost.   But is DMARC that “messed up?”   
I mean, just like ADSP, it is abandonment material, honestly, easy.

But DMARC is big and it did one thing for the mail industry — the Lookup added 
to the SMTP process.  Moat SMTP receivers will do the the _dmarc.from-domain 
lookup.

DMARC is the #1 lookup record for this purpose,  a DKIM Policy Model.

We said very early on that but will take a while to get traction for a DKIM 
Policy model where lookups come with a good payoff, otherwise it is just wasted 
calls. 

Let’s leverage the lookup using a protocol language for a wide security 
coverage that offers dynamic rejection to clean the mail stream before passing 
it to local proprietary reputation databases.

Happy July 4th, Be safe.

—
HLS

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

[dmarc-ietf] dmarc - Requested session has been scheduled for IETF 117

["IETF Secretariat"]

Dear Barry Leiba,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


dmarc Session 1 (1:00 requested)
Friday, 28 July 2023, Session II 1200-1330 America/Los_Angeles
Room Name: Golden Gate 6 size: 80
-


iCalendar: https://datatracker.ietf.org/meeting/117/sessions/dmarc.ics

Request Information:


-
Working Group Name: Domain-based Message Authentication, Reporting & 
Conformance
Area Name: Applications and Real-Time Area
Session Requester: Barry Leiba


Number of Sessions: 1
Length of Session(s): 
Number of Attendees: 30
Conflicts to Avoid: 

   


Participants who must be present:
  Alessandro Vesely
  Alex Brotman
  John R. Levine
  Scott Kitterman
  Todd Herr

Resources Requested:
  Experimental Room Setup (U-Shape and classroom, subject to availability)

Special Requests:
  Please avoid ART-area and Sec-area BoFs
-


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

Great question.

I’ve been around since the beginning as a very strong DKIM Policy advocate, 
watching everything, my dumb attempt to summarize:

1) The idea of “reporting” was considered a testing thing.  Redundant,. 
DomainKeys and DKIM had -t test keys.  I believed and others as well, felt 
reporting was an attack vector. I included reporting ideas in DSAP but the 
format was not defined. The section was left TBD.

2) Murray was working on reporting methods with a format.  He was obviously 
filling a need out there.

3) I did not hear of anyone honoring ADSP rejects because of the known indirect 
mail problems.

4) ADSP was abandoned and replaced with Super ADSP aka DMARC which introduced a 
reporting and compliance concept.  It had a strong policy idea.

5) I totally under estimated the administrator direct for reports.  But I still 
didn’t believe it in.  It’s for testing only, right? 

6) I did not hear of anyone rejecting on DMARC p=reject. So it was just about 
Reporting & Conformance.

7) Then YAHOO.COM , the patented inventor of this all this 
starting with DomainKeys, the first with a built-in `o=` tag policy concept, 
was the first big system to honor published DMARC strict policies.

8) Now DMARC become about Handling and proper SMTP integration with SPF.

The end!

Happy July 4th Weekend. Be safe!!

—
HLS




> On Jun 30, 2023, at 2:22 PM, Todd Herr 
>  wrote:
> 
> Genuine curiosity question here for those who were around at the beginning...
> 
> Why is the mechanism called "Domain-based Message Authentication, Reporting, 
> and Conformance" and not "Domain-based Message Authentication, Reporting, and 
> Disposition"? Perhaps a better question, why is "conformance" in the name of 
> the mechanism?
> 
> I ask because I'm writing up some stuff for internal use, and I got curious 
> as to how conformance is defined or explained in RFC 7489, and well, it's 
> not. The word appears five times in RFC 7489, and each occurrence is in the 
> context of spelling out the full name of the mechanism.
> 
> I am not looking to change the name of the mechanism; I'm just genuinely 
> curious how the name was arrived at.
> 
> -- 
> Todd Herr  | Technical Director, Standards & Ecosystem
> e: todd.h...@valimail.com 
> p: 703-220-4153
> m: 703.220.4153
> 
> This email and all data transmitted with it contains confidential and/or 
> proprietary information intended solely for the use of individual(s) 
> authorized to receive it. If you are not an intended and authorized recipient 
> you are hereby notified of any use, disclosure, copying or distribution of 
> the information included in this transmission is prohibited and may be 
> unlawful. Please immediately notify the sender by replying to this email and 
> then delete it from your system.
> ___
> 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] easier DKIM, DMARC2 & SPF Dependency Removal

[Hector Santos]

> On Jun 30, 2023, at 3:32 PM, Murray S. Kucherawy  wrote:
> 
> On Fri, Jun 30, 2023 at 12:21 AM Jan Dušátko 
> mailto:40dusatko@dmarc.ietf.org>> 
> wrote:
>> Scott, Barry,
>> as far as I understand, SPF are historic technology,
> 
> Not in any official capacity.  RFC 7208 is a Proposed Standard.  In fact, in 
> IETF terms, it enjoys higher status than DMARC does right now.
> 
> The status of these protocols is not under discussion.  The only question is 
> whether DMARC should continue to factor SPF results into its output.


If I am reading the group right, using the suggested `auth=` tag for 
explanation, it appears the editor wants the new DMARCbis default to be:

auth=dkim

And it would required an explicit tag like;

auth=spf,dkim

to express a desire for spf to be in the evaluation.  This offers DMARCbis 
backward compatibility.   This would be the one “upgrade” change a domain would 
need to make, an optional “extended behavior” to make it behave like DMARC 
today.  The default behavior today is auth=spf,dkim.  DMARCbis’s default would 
be auth=dkim.

I am saying it sounds like this.  

Overall, imo, it is never a good idea to exerted changes on domains with bis 
specs, requiring them to change their current DMARC record to reinforce the 
security level they want using SPF in DMARC evaluation. 

—
HLS

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

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

[Murray S. Kucherawy]

On Fri, Jun 30, 2023 at 12:21 AM Jan Dušátko  wrote:

> Scott, Barry,
> as far as I understand, SPF are historic technology,
>

Not in any official capacity.  RFC 7208 is a Proposed Standard.  In fact,
in IETF terms, it enjoys higher status than DMARC does right now.

The status of these protocols is not under discussion.  The only question
is whether DMARC should continue to factor SPF results into its output.

-MSK
___
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?

[Seth Blank]

Given Todd's comment that "DMAR" is well defined, but "C" is not-- is it
worth explanatory text in the document? I don't think there's any real
confusion about what Conformance means. Is it a weird gap to leave while
we're updating the document, or does no one think it matters?

On Fri, Jun 30, 2023 at 12:06 PM Dotzero  wrote:

>
>
> On Fri, Jun 30, 2023 at 2:31 PM Murray S. Kucherawy 
> wrote:
>
>> On Fri, Jun 30, 2023 at 11:22 AM Todd Herr > 40valimail@dmarc.ietf.org> wrote:
>>
>>> Why is the mechanism called "Domain-based Message Authentication,
>>> Reporting, and Conformance" and not "Domain-based Message Authentication,
>>> Reporting, and Disposition"? Perhaps a better question, why is
>>> "conformance" in the name of the mechanism?
>>>
>>
>> Two reasons I can think of:
>>
>> 1) "Conformance" describes the test as to whether a message meets the
>> required authentication test(s).  And one can reasonably infer from
>> "Conformance" that a message which doesn't conform to the published
>> authentication policy will be dealt with accordingly.
>>
>> 2) DMARC's antecedents (e.g., ADSP) were still part of what we considered
>> email authentication, which is covered by the "A".
>>
>> -MSK
>>
>
> "Conformance"  was about conformance to the requested policy disposition.
> We (dmarc.org participants) tossed around various acronyms as we
> discussed the name. I'll also point out that the immediate antecedent to
> DMARC was MOOCOW. ADSP was not a consideration other than problems to
> avoid. "Authentication" referenced authenticating the domain associated
> with the RFC822 From email address.
>
> Michael Hammer
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Seth Blank * | Chief Technology Officer
*e:* s...@valimail.com
*p:*

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
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?

[Dotzero]

On Fri, Jun 30, 2023 at 2:31 PM Murray S. Kucherawy 
wrote:

> On Fri, Jun 30, 2023 at 11:22 AM Todd Herr  40valimail@dmarc.ietf.org> wrote:
>
>> Why is the mechanism called "Domain-based Message Authentication,
>> Reporting, and Conformance" and not "Domain-based Message Authentication,
>> Reporting, and Disposition"? Perhaps a better question, why is
>> "conformance" in the name of the mechanism?
>>
>
> Two reasons I can think of:
>
> 1) "Conformance" describes the test as to whether a message meets the
> required authentication test(s).  And one can reasonably infer from
> "Conformance" that a message which doesn't conform to the published
> authentication policy will be dealt with accordingly.
>
> 2) DMARC's antecedents (e.g., ADSP) were still part of what we considered
> email authentication, which is covered by the "A".
>
> -MSK
>

"Conformance"  was about conformance to the requested policy disposition.
We (dmarc.org participants) tossed around various acronyms as we discussed
the name. I'll also point out that the immediate antecedent to DMARC was
MOOCOW. ADSP was not a consideration other than problems to avoid.
"Authentication" referenced authenticating the domain associated with the
RFC822 From email address.

Michael Hammer
___
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 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.

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?

[Murray S. Kucherawy]

On Fri, Jun 30, 2023 at 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"? Perhaps a better question, why is
> "conformance" in the name of the mechanism?
>

Two reasons I can think of:

1) "Conformance" describes the test as to whether a message meets the
required authentication test(s).  And one can reasonably infer from
"Conformance" that a message which doesn't conform to the published
authentication policy will be dealt with accordingly.

2) DMARC's antecedents (e.g., ADSP) were still part of what we considered
email authentication, which is covered by the "A".

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

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

[Todd Herr]

Genuine curiosity question here for those who were around at the
beginning...

Why is the mechanism called "Domain-based Message Authentication,
Reporting, and Conformance" and not "Domain-based Message Authentication,
Reporting, and Disposition"? Perhaps a better question, why is
"conformance" in the name of the mechanism?

I ask because I'm writing up some stuff for internal use, and I got curious
as to how conformance is defined or explained in RFC 7489, and well, it's
not. The word appears five times in RFC 7489, and each occurrence is in the
context of spelling out the full name of the mechanism.

I am not looking to change the name of the mechanism; I'm just genuinely
curious how the name was arrived at.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Alessandro Vesely]

On Fri 30/Jun/2023 04:07:46 +0200 Tero Kivinen wrote:

Alessandro Vesely writes:

[...]



ESPs can provide include files for those who wish otherwise.


I know that some companies in finland has included the iki.fi 
IP-addresses ranges to their SPF records, because they had several 
complains from people of SPF failures when they were sending emails to 
iki.fi addresses. We even added _spf.iki.fi DNS record for them to use 
for their include when it was requested, but I do not consider that 
good practice for solving issues of the SPF.



Agreed.  Before -all, tana.it's SPF record sports a directive like so:

?exists:%{ir}.list.dnswl.org

Neither this is a good practice, as receivers should consult a whitelist of 
their choice without having to obey an explicit request.  And dnswl.org count 
the queries they receive from each host.


IMHO, forwarding agreements should be set up at the very moment when the 
senders fixes the target address in a dot-forward recipe.



Best
Ale
--






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

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

[Jan Dušátko]

Scott, Barry,
as far as I understand, SPF are historic technology, but still have a 
reason why to use it. In my opinion (and concerns), it is also necessary 
to be aware of the extension of the individual protection methods 
provided by senders (amount of domains). This is not a deep analysis. It 
is possible that the numbers given will not be accurate.

SPF    87%
DKIM    13%
DMARC 63%
ARC         5%
As technologies are deployed not in a technological continuity, but 
according to the needs of system owners, they are therefore set 
intersections. For this reason, relying only on the combination of 
DKIM+DMARC technology could be unfortunate.
In terms of provability, each DKIM signed email will be sent from the 
owner of the authorized servers. Ideally, therefore, it is not necessary 
to combine SPF and DKIM, only DKIM could be sufficient. However, the 
following situations are a problem. As a rule, DKIM+DMARC is not fully 
implemented, part of the domains are protected by DKIM, part by DKIM + 
SPF, part by SPF only.
- Only DKIM and DMARC are implemented, yet the SPAM distributor sends an 
email without the DKIM signature and without the key information.
- Only DKIM and DMARC are implemented, and a signed email is available. 
The SPAM distributor starts repeatedly sending the same email 
(equivalent to a DOS attack).
- Only DKIM and DMARC are implemented, and a signed email based on 
RSA+SHA1 is available. Because it is possible to find collisions for 
SHA1, and the digital signature is actually an "encrypted hash," it is 
possible to send counterfeit mail with a signature that looks genuine. 
The solution is to use explicitly h=sha2, but if not specified, it is 
also possible to "downgrade the signature" against another key on this 
domain supporting SHA1 (any SHA1-based signature will be used).


These attacks are the first that came to my mind. How we can mitigate 
that threat? According to owner authorization of IP addresses, they 
protect against a different kind of attack than the digital signature by 
using DKIM.


On the other hand, SPF can bring beside of advancing security particular 
security reduction. Simply because most of services are "shared in 
cloud" right now. Cloud service providers generally provide the extent 
to which virtual services can operate. It is not a question of who has 
or does not have the ability to use the service (in meaning that service 
are approved to send e-mails beside of domain). In this case, it is not 
a problem to create a system in the cloud technology that starts mimic 
and send junk mail instead of an authorized organization. The methods of 
correction are reactive, so it will take some time before such an attack 
is detected and mitigated. However, even a limitation of scope can be 
supported by DKIM, as it limits the space from which an attacker can 
operate.


The whole problem is a single one. What tools to provide the domain 
owner with to set up a policy to protect the reputation of its mail 
services. From this, another question arises:

- To what extent can domain service managers' knowledge be trusted?
- Is it possible to set up policy processing rules so that non-standard 
situations like missing signature can be handled, or allow the owner to 
define how signatures will be used?
- Is it possible to unambiguously describe the rules to avoid 
implementation errors?

- How will the problem of mail forwarders and mailing lists be addressed?

regards

Jan


Dne 28. 6. 2023 v 21:43 Scott Kitterman napsal(a):

I think it's quite relevant.

The assumption that this is based on is there's a need to specify because SPF 
data is not reliable enough for everyone.  If that premise is correct (I don't 
agree with it, but it's a separate issue), then I think telling people that 
they should use DKIM because it IS reliable, when it's got its own issues isn't 
a great idea.

I've been mulling this whole topic over and I think I'm close to having mulled 
it enough to have a useful proposal.  SPF bad, DKIM good is a gross 
over-simplification, but so is if it passed SPF, it's authorized, so go whine 
at the provider.

Scott K

On June 28, 2023 6:32:41 PM UTC, Barry Leiba  wrote:

I think DKIM replay is largely irrelevant to this discussion (about
the sender specifying which authentication to use), because if that's
your biggest concern with respect to DMARC, then "SPF only" is the
answer.  "SPF *and* DKIM" is not any better than that.


You seem to imply that auth=dkim+spf wouldn't be effective against DKIM reply

(Assuming you mean "replay".)  "SPF and DKIM" does not give any
benefit beyond "SPF only" in this case.

Look, either SPF fails because the message was relayed illegitimately...
...or SPF passes because the replayer used the sender's legitimate
infrastructure to do the replay.

Barry

On Wed, Jun 28, 2023 at 12:43 PM Alessandro Vesely  wrote:

Thank you for your analysis.  However, it doesn't touch on DKIM replay.

I know this topic belongs to the ot