Re: [dmarc-ietf] ARC questions

[Brandon Long <[e-mail]>]

On Tue, Nov 24, 2020 at 5:27 PM Michael Thomas <[e-mail]> wrote:

>
> On 11/24/20 4:56 PM, Brandon Long wrote:
>
>
>
> On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas <[e-mail]> wrote:
>
>>
>> Our experience also showed that more than one hop is quite common in
>> enterprise deployments,
>> and those are also the places where the most complexity arises.  Others
>> shared our experience
>> as well.
>>
>> That's more than one modifying intermediary in *separate* administrative
>> domains? Within your own administrative domain there shouldn't be an issue
>> of trust since you can trust your own servers auth-res and that they are
>> not maliciously trying to forge an auth-res for better treatment. and
>> course it's best to stop a bad message as soon as possible in the mail
>> pipeline if for no other reason than why waste the resources.
>>
> The administrative domain in practice tends to be per-vendor and
> multi-tenant.  Ie, gsuite/gmail is on google.com, various third party
> anti-spam gateways also different, on-premise being also separate.  Passing
> that trust between domains is one of the things that ARC can handle.
>
> One of the failings of many, many ietf documents is to not tell the story
> of what exactly the problem is and why the protocol is needed. It's really
> frustrating to the reader to not have the context of endless wg list
> discussions distilled so that an outsider can understand the design
> tradeoffs. I still don't understand why a DKIM signature was a "poor
> choice". That's especially true when something is an experiment that
> assumedly has yes/no endpoint.
>
To summarize what I said already in this thread, DKIM is taken by many
receivers as the responsible party for a message, in both spam and phishing
classifiers, with the latter being perhaps more relevant.
DMARC is the one example of that.  DKIM signing a message that transits
your system allows for reputation washing of the original message.  The ARC
chain is specified as a relay responsibility, which is a lesser burden.

Ignoring the existing usage of DKIM, DKIM+A-R would only work for a single
hop, and lead to some complication compared to the other DKIM signatures
already on the message.

DKIM is not the only thing that can be reputation washed, SPF can as well.
821.FROM rewriting is more common, so there are work-arounds.  OTOH, SPF
doesn't survive forwarding, but with ARC you can forward it.  DKIM+A-R
would only work for a single hop, and lead to some complication compared to
the other DKIM signatures already on the message.


> So mtcc.com is now hosted by gsuite (::sigh::), so you're saying that it
> would run into problems? I haven't put up a DMARC policy, but if I did I
> might run into issues with false positives? Like I said, I'm trying to get
> my head around what the actual problems are, and this is coming from a
> person who stressed mightily from the very beginning about the mailing list
> problem.
>
It's unlikely you have a complicated mail flow involving multiple vendors,
but certainly there are plenty of configuration options alllowing folks to
shoot themselves in the foot.

> Well sure, I'm sure it can happen but is it common enough to worry about?
>> And I'm still not convinced that figuring out who signed what and which
>> auth-res it belonged to is in insurmountable problem. for one, there are
>> received headers which better not be getting out of order to help correlate
>> with the messages' path through intermediary verifiers too.
>>
> So, we do have some Received header walking code, and allow admins to set
> up the list of IPs that are considered "internal" (beyond private
> addresses)... but O365 uses public IPs internally and
> has a huge and unpublished ranges of them, making it nearly impossible for
> admins to maintain a list.  Obviously we can all add code to handle
> Microsoft specially... and whichever other ones come up.
>
> But can't you trust the received headers once you have possession of the
> message within your domain? I'm sorry if I'm being dense here but received
> headers are definitely ordered and if you loan out a message to be
> processed by a different domain and they aren't trustworthy, that's the
> least of your problems. That's part of the overall problem though: it's
> really hard to understand what the problem here actually is. Explain it
> like I'm five :)
>
For now, our received header walking code is for handling inbound
gateways.  If you use both O365 and GSuite, and use O365 as your MX before
forwarding to Google, there are many cases where they will break all DKIM
signatures (and obviously SPF) before reaching Google's MX.  Our workaround
is to specify your internal IPs to us, so we can walk past those received
headers to the first one added by your external MX.

Should these things use IP addresses for these things?  Probably not.  Some
sort of SMTP-AUTH could potentially be used to gateway more directly
between them, but we'd still need to disable most of our
spam/phishing pipelines which are dependent on reputation.

With ARC, we can instead say "trust this arc admd" and have the data passed
directly, and also work around the DKIM breakage.

As for another comment in the thread about adding two signatures per hop,
there was a suggestion that it could be replaced with a single signature
per hop near last call with some loss of information (maybe), but it was
decided to move forward with the existing solution that already had several
implementations and was experimental anyways.

As for how complicated it is to implement, I think starting from a DKIM
implementation it's fairly straight-forward... though obviously that
depends a bit on how your DKIM implementation was composed.  I think my
initial changes to dkimpy to add ARC support only took a couple days.  It's
not really an indication of how well written (or not) the RFC is, given
familiarity with the design prior to draft.

Brandon