Re: [dmarc-ietf] ARC Dependency?

[Douglas Foster]

The real quirk is that Microsoft is using ARC for something for which it
was never intended.   I am open to fixing ARC to support what they want to
do, but their current implementation only exposes how easily an attacker
can misuse ARC to "authenticate" his own stuff.

If ARC is to be used to add extra authentication at origination, it would
need to include the other authentication mechanisms:
- User credentials (Web interface, MAPI, ActiveSync, Exchange Web Services,
Authenticated SMTP, API.)
- Sever-to-server credentials
- Trusted IP
- Known Client (probably supplemented by one of the above) for handoff from
an originating organization to its outbound filtering services

In the absence of those options, Microsoft seems willing to make up phony
authentication results, just like a spammer would.

DF


On Sat, Mar 25, 2023 at 8:45 AM Mark Alley  wrote:

> There have been noticeable quirks with the method that Microsoft has
> attempted ARC implementation (regarding outbound sealing).
>
> For enterprise/business tenants, these customers have full control over
> their mail routing (such as, say, sending outbound mail through a third
> party spam filter or another service).
>
> With this scenario, it is a common configuration to remove Office 365's
> SPF include mechanism from a domain's SPF record; since O365 is no longer
> directly sending mail to external receivers, the filter is now the last hop.
> Additionally, as is common with this configuration, DKIM signing will also
> be done at the edge with (not on office 365).
>
> One can start to see the issue with this scenario. The Microsoft ARC set
> added here will fail immediately upon application for these customers (and
> there are an extremely large amount of tenants with this configuration),
> and thus preventing further additions and any usefulness to the ARC by
> receivers down the line (such as google) due to its immediate invalidity.
>
> The argument can be made to simply, "keep O365 in a domain's SPF record",
> to fix the ARC authentication in this scenario, but this is not a desired
> configuration given that it is currently possible to create SPF aligned
> mail from any Office 365 tenant using any domain desired (Outside of the
> jurisdiction of the actual domain's tenant).
>
> You don't see this issue with many other sealers currently because this is
> only possible at the moment (as far as I know) with ARC sealers that give
> complete control over a domain's egress mail routing, DNS, *and* also seal
> ARC on egress mail. For example, this is not a problem for Zohomail, or
> Microsoft consumer domains (Hotmail, MSN, live, outlook, etc.), who also
> seal ARC on egress mail, because the customer does not control the domain
> being sent from. There is no opportunity for this condition to occur.
>
> Not to detract from their efforts towards its use, as it *does* work as
> intended in expected inbound scenarios as-is currently in O365, but there
> should definitely be more consideration given by ARC sealers as to when an
> ARC set is applied. Possibly by giving sealing condition capabilities to
> the customer?
>
> - Mark Alley
>
>
>
>
>
> On Fri, Mar 24, 2023, 6:18 PM Seth Blank  wrote:
>
>> Microsoft is using ARC quite heavily, and has reported on this list and
>> at M3AAWG of the impact it makes
>>
>> Microsoft even has on their public roadmap that tools are being built for
>> their customers to enable per-customer sealers that they choose to trust:
>> https://www.microsoft.com/en-us/microsoft-365/roadmap?filters==dmarc
>>
>> On Fri, Mar 24, 2023 at 5:06 AM Steven M Jones  wrote:
>>
>>> On 3/24/23 3:48 AM, Douglas Foster wrote:
>>> >
>>> > Do we know if any entity other than Google is successfully using ARC
>>> > as an evaluation tool?
>>>
>>>
>>> FWIW: In late 2021 a "German company" reported that it was able to
>>> "recover" about 10% of messages that had failed other authentication
>>> checks by validating ARC.
>>>
>>> --S.
>>>
>>>
>>> ___
>>> 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] ARC Dependency?

[Douglas Foster]

Welcome back, Hector. ARC has important differences from ATPS.

ARC allows a forwarder to request trust from an evaluator, depending upon
the level of trust that the evaluator is willing o grant to the
intermediary.   The originator is not involved.  The evaluator may be able
to use ARC data to accurately identify the originator and assign reputation
to that originator.

ATPS allows an originator to ask an evaluator to trust an intermediary.
 It requires the originator to know who will be forwarding his messages,
and whether those entities are trustworthy or not.The evaluator has to
trust the intermediary, the originator, and the originator's judgement.
 This is a less plausible request.

Forwarding without ARC will partially or fully hide the identity of the
originator, which makes ARC desirable for any forward, with or without
changes..

I just regret that ARC does not ensure that all of the pre-forwarding
identities (server, SMTP address, and From address) can be extracted from
the ARC data, so complete identification of the originator is not assured.

DF



DF

On Sun, Mar 26, 2023 at 2:26 PM Hector Santos  wrote:

> Wouldn’t it be far easier to add the trusted 3rd party domains in some DNS
> table or lookup, ala an ATPS-like protocol? The RFC5322 ARC overhead is
> horrendous. Never mind the complexity evolved to implement.
>
> On Mar 24, 2023, at 7:17 PM, Seth Blank  wrote:
>
> Microsoft is using ARC quite heavily, and has reported on this list and at
> M3AAWG of the impact it makes
>
> Microsoft even has on their public roadmap that tools are being built for
> their customers to enable per-customer sealers that they choose to trust:
> https://www.microsoft.com/en-us/microsoft-365/roadmap?filters==dmarc
>
> On Fri, Mar 24, 2023 at 5:06 AM Steven M Jones  wrote:
>
>> On 3/24/23 3:48 AM, Douglas Foster wrote:
>> >
>> > Do we know if any entity other than Google is successfully using ARC
>> > as an evaluation tool?
>>
>>
>> FWIW: In late 2021 a "German company" reported that it was able to
>> "recover" about 10% of messages that had failed other authentication
>> checks by validating ARC.
>>
>>
> ___
> 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] ARC Dependency?

[Douglas Foster]

Seth, your link led me to this link:

https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-dmarc-configure?view=o365-worldwide#how-microsoft-365-utilizes-authenticated-received-chain-arc

Which says,

"Microsoft 365 currently utilizes ARC to verify authentication results when
Microsoft is the ARC Sealer, but plan to add support for third-party ARC
sealers in the future."


My translation:

"When a Microsoft-hosted domain authenticates a message and then forwards
it to another Microsoft-hosted domain, Microsoft is able to recognize the
forward and not classify the message the message as a malicious
impersonation."


I cannot see how Microsoft needed ARC to accomplish this underwhelming feat.

DF





On Fri, Mar 24, 2023 at 7:18 PM Seth Blank  wrote:

> Microsoft is using ARC quite heavily, and has reported on this list and at
> M3AAWG of the impact it makes
>
> Microsoft even has on their public roadmap that tools are being built for
> their customers to enable per-customer sealers that they choose to trust:
> https://www.microsoft.com/en-us/microsoft-365/roadmap?filters==dmarc
>
> On Fri, Mar 24, 2023 at 5:06 AM Steven M Jones  wrote:
>
>> On 3/24/23 3:48 AM, Douglas Foster wrote:
>> >
>> > Do we know if any entity other than Google is successfully using ARC
>> > as an evaluation tool?
>>
>>
>> FWIW: In late 2021 a "German company" reported that it was able to
>> "recover" about 10% of messages that had failed other authentication
>> checks by validating ARC.
>>
>> --S.
>>
>>
>> ___
>> 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] ARC Dependency?

[Hector Santos]

Wouldn’t it be far easier to add the trusted 3rd party domains in some DNS 
table or lookup, ala an ATPS-like protocol? The RFC5322 ARC overhead is 
horrendous. Never mind the complexity evolved to implement.

> On Mar 24, 2023, at 7:17 PM, Seth Blank  wrote:
> 
> Microsoft is using ARC quite heavily, and has reported on this list and at 
> M3AAWG of the impact it makes
> 
> Microsoft even has on their public roadmap that tools are being built for 
> their customers to enable per-customer sealers that they choose to trust: 
> https://www.microsoft.com/en-us/microsoft-365/roadmap?filters==dmarc
> 
> On Fri, Mar 24, 2023 at 5:06 AM Steven M Jones  > wrote:
>> On 3/24/23 3:48 AM, Douglas Foster wrote:
>> >
>> > Do we know if any entity other than Google is successfully using ARC 
>> > as an evaluation tool?
>> 
>> 
>> FWIW: In late 2021 a "German company" reported that it was able to 
>> "recover" about 10% of messages that had failed other authentication 
>> checks by validating ARC.
>> 

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

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Mar 26 06:00:04 2023

[John Levine]

   Count|  Bytes |  Who
++---
 14 ( 100%) | 159741 ( 100%) | Total
  4 (28.6%) |  71568 (44.8%) | Wei Chuang 
  3 (21.4%) |  33298 (20.8%) | Douglas Foster 

  1 ( 7.1%) |  13727 ( 8.6%) | Mark Alley 
  1 ( 7.1%) |  12113 ( 7.6%) | Dotzero 
  1 ( 7.1%) |   8800 ( 5.5%) | Scott Kitterman 
  1 ( 7.1%) |   7501 ( 4.7%) | Seth Blank 
  1 ( 7.1%) |   5501 ( 3.4%) | Benny Pedersen 
  1 ( 7.1%) |   4373 ( 2.7%) | Steven M Jones 
  1 ( 7.1%) |   2860 ( 1.8%) | John Levine 

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