Re: [dmarc-ietf] ARC Dependency?

2023-03-26 Thread 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?

2023-03-26 Thread 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?

2023-03-26 Thread 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?

2023-03-26 Thread 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

Re: [dmarc-ietf] ARC Dependency?

2023-03-25 Thread Mark Alley 
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

Re: [dmarc-ietf] ARC Dependency?

2023-03-24 Thread Benny Pedersen 

Seth Blank skrev den 2023-03-25 00:17:

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


i dont like there model of make pr custommer trusted by arc, it should 
imho be trusted on forwarder only, not on random custommer


but ok if it can be made complicated lets do-it, like microsoft-edge on 
linux, where firefox say web.skype.com works better with edge, hmm


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

Re: [dmarc-ietf] ARC Dependency?

2023-03-24 Thread Seth Blank 
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

Re: [dmarc-ietf] ARC Dependency?

2023-03-24 Thread Steven M Jones 

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-ietf] ARC Dependency?

2023-03-24 Thread Douglas Foster 
This question is mostly for the chairs:

Does completion of DMARCbis have any dependency on whether ARC is
successful or not as an evaluation tool?

Do we know if any entity other than Google is successfully using ARC as an
evaluation tool?

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