Re: [dmarc-ietf] ARC questions

[Brandon Long <[e-mail]>]

On Mon, Nov 23, 2020 at 12:48 PM Dave Crocker <[e-mail]> wrote:

> On 11/23/2020 12:15 PM, Brandon Long wrote:
>
> On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker <[e-mail]> wrote:
>
>> > Yes, of course, a handling agent can do it, but there are plenty of
>> reasons
>> > why they shouldn't.
>>
>> Please enumerate and explain.  If it's that dangerous, we should
>> document it, especially I don't recall that constraint being in any of
>> the design or standardization discussions.
>>
>
> DKIM often ties a domain to reputation and other anti-spam features.  If
> you
> forward spam to another host and sign it while forwarding, then the other
> host
> will think you send spam.
>
> Well, ummm... errrr... yes.  That's because, in such circumstances, you do.
>
> More significantly, the signature makes sure that such as an assessment
> will only be made accurately, rather than penalizing you for problematic
> mail that is attributed to you but that you did not handle.
>
If the result is marking all of the mail from that mailing list as spam,
then you've likely done your users a disservice.  Being able to
differentiate is useful.  Also, forwarders often don't have all of
the signals that the user's mailbox does.. not the least of which is that
different recipients have different judgements on what is spam, and the
"this is spam" signal rarely makes it back to the forwarder.

> DMARC ties DKIM to the From header and at least is interpreted as being an
> anti-phishing feature.  DKIM signing mail that you forward could mean
> upgrading
> a phishing message to passing DMARC.
>
> I don't understand.  The first sentence makes sense to me, but the second
> doesn't.
>
> "Upgrading...to passing DMARC only applies if a) the signature matches the
> From: field domain, and b) that domain has an associated DMARC record.  But
> if you don't watch DMARC to apply in that case, what is the DMARC record
> there fore?
>
I send a phishing message to a mailing list or alias at a domain with a
>From header of that domain, and the list blindly
re-signs all mail sent to the list, I've now "authenticated" the spoofed
message, and it will now "pass" DMARC.  Perhaps it
upgraded from a quarantine to none, since the mailing list doesn't have the
concept of a spam folder, or perhaps the sales@ team
has decided they want all of the forwarded messages, even if probably spam,
so that they can go through them to make sure...
but it lost the quarantine disposition on the forward when it gained
authentication.

This recent article also goes into things that DKIM signatures imply:
>
> https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/
>
> The level of condescension, ignorance, and error throughout that article
> is impressive.  Given that it was written by someone whose profession
> requires extreme care about complex matters, the level of carelessness in
> the article is especially unfortunate.
>
> Conveniently, he put his biggest error in bold font:
>
>      "*DKIM provides a life-long guarantee of email authenticity that
> anyone can use to cryptographically verify the authenticity of stolen
> emails, even years after they were sent."*
>
> DKIM does no such thing.
>
> and this was quickly followed by the normal-font:
>
>    "The key design goal of DKIM was to prevent spammers from forging
> emails *while in transit*. "
>
> This, too, is not what DKIM does.  DKIM provides a noise-free channel for
> assessing signers, not for detecting spammers.  The difference is
> important; and I claim fundamental.
>
> ps. making sure that DKIM signature become invalid  relatively soon -- I
> think that removing the keys is simpler and just as effective as publishing
> the private keys -- seems like a reasonable suggestion.
>
>
> Perhaps this all means that DKIM has been used for more than it was
> intended for.
>
> "More than" suggests that the use has legitimacy.  It doesn't.
>
We don't always have control over how our work is used.  If I proposed
extending a standard in a new direction that would
be perfectly fine with the original intent of the standard, and that
clashed with how the standard had come to be used in
practice, my extension is DOA.

> >      > Intermediaries don't want to take ownership of the message in that
>> >      > sense, though there
>> >      > are some mailing lists that do.
>> >
>> >     Signing with DKIM does not take 'ownership'.
>> >
>> >
>> > Yes, responsibility is the proper word.  My point survives the word
>> change.
>>
>> I disagree.
>>
>>
>> > DKIM says the domain takes responsibility for the message, while ARC
>> says
>> > the domain takes responsibility for evaluating the status of the
>> message
>> > when
>> > they received and forwarded it.
>>
>> This implies that the word 'some' is irrelevant.  It isn't.  And it was
>> included intentionally.
>>
>
> Automated systems can't really tell how much responsibility an
> intermediary was
> intending to take for the message.
>
> People who write them can.
>
>
> OTOH, they typically are using it only for a certain
> purpose, so they assume that the intermediary took responsibility in the
> sense that they
> want... or rather, the people who wrote the code do.  Or the journalist
> writing the story.
>
> ARC was specified to have a more specific responsibility,
>
> Forgive me but I think that:
>
>    Authenticated Received Chain (ARC) creates a mechanism for individual
>    Internet Mail Handlers to add their authentication assessment to a
>    message's ordered set of handling results.
>
>
> specifies a nature and responsibility pretty much identical to what DKIM
> claims.  The enhancements are a) chaining, and b) carriage of earlier
> assessments.  But in terms of 'responsibility', this reads the same as DKIM.
>

I don't see how "claim some responsibility" is the same as "add their
authentication assessment".  I guess they are claiming
responsibility for the assessment, but that's a very specific thing, and
not the "some [unknown] responsibility"

> and as different from DKIM so
> that it wasn't mistaken for the uses that people were already using DKIM
> for.
>
> Oh?
>

This was definitely a topic of discussion during the initial meetings where
we went from XOAR to ARC.

Brandon