On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote:
>> On 5 Aug 2023, at 02:43, Jesse Thompson <z...@fastmail.com> wrote:
>>
>> On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote:
>>> I agree with this and have been working to recruit folks to come here. I’ll
>>> also be in Brooklyn and pitching the need for participation in the IETF
>>> working group from folks in the email space who are seeing issues with
>>> this.
>>
>> I'll be there and interesting in participating. As an ESP/infrastructure
>> provider I can say that we are "having" the issue, but can't say that we
>> "seeing" the issue since visibility is only available to anti-spammers, and
>> domain owners (who receive DMARC reports).
>
> A big driver of the work is actually Google. As I understand it, they are
> having issues because the replay attackers are successfully stealing
> reputation of otherwise good senders in order to bypass some spam filtering.
> The replay attackers aren’t sending what we commonly think of as spam through
> the signers - as the message is sent to one recipient (not bulk) and it is
> opt-in (that recipient wants and has asked for the mail).
This is accurate from my observation. It takes only a single message which
evades content filters, and the attacker is the first recipient, who will not
report it as abuse.
Which is why an earlier "just don't send spam" comment seemed to be borderline
FUSSP rhetoric. If the message isn't detected by the receiver (who has the most
visibility into the type of mail its users want to receive) then how can a
sender be held to a higher standard of detection with less visibility?
The reputation they are stealing is that of the DKIM domain(s) associated with
the signatures on the message (whether they are aligned to the rfc5322.From or
not). So, adding more signatures to convey more fidelity would seemingly help
solve the problem because receivers could better fingerprint good patterns from
bad patterns. But replayers could just remove the higher fidelity signatures.
To solve that, I think we need Mandatory Tags for DKIM Signatures [1] 3.3.
Forward signature (!fs) tag.
[1] https://datatracker.ietf.org/doc/html/draft-levine-dkim-conditional-04
3.3. Forward signature (!fs) tag
The "!fs" mandatory tag means that the signature is only valid if an additional
signature is present in the message. The value of the !fs tag is a domain name
that is the value of the d= tag of the additional signature. The condition is
satisfied if the message includes at least one valid DKIM signature header
field with responsible domain (the d= tag) being one specified by the !fs tag.
Chained !fs tags are valid and may be useful in scenarios with multiple levels
of forwarders. DKIM verifiers SHOULD handle at least three levels of !fs
chaining.
>
>> I recall various assertions that the reason why DMARC has been successful is
>> primarily because of the Reporting benefits (and I certainly agree with this
>> assertion from my background as an enterprise domain owner), while the
>> Conformance benefits seem to be more elusive (as evidenced by the
>> inconsistent adoption by receivers and the debates around interoperability
>> issues with indirect mail streams). Of course, the Authentication benefits
>> are provided by DKIM/SPF, and yet DKIM signers have no standard mechanism to
>> receive reports of how their signatures are being misused.
>>
>> If people think that Reporting is the reason why DMARC has been successful,
>> then could we conclude that the lack of Reporting to DKIM signers is a
>> problem worth addressing?
>
> That’s an interesting thought. I’m thinking the next step down - will it help
> minimize the problem for senders? ie, would reporting be fast enough that
> they could revoke a key?
The reason why key revocation doesn't work today (other than DNS TTL) is
because the replayed keys are in domains that too broadly cover desirable mail.
The key which should be revoked should be the one that most narrowly stops only
the replayed mail and not stop otherwise good mail. In the high-fidelity
multi-key model with forward signature tags, revocation of a single key to
break the chain seems possible. How quickly it can be done is lower bound to
how quickly a receiver's reputation algorithms can identify fingerprint any
message down to the highest fidelity key, but the risk of DOS implies there
needs to be some kind of moderation.
I think the DNSxL approach is more flexible and timely than revoking the key
from DNS. So, while anti-spammers are in a better position to create and
maintain DNSxLs for thwarting replay attacks, I was thinking about a model
where ESPs index customers with DKIM signatures in domains that are unique per
customer, or perhaps even more granular. No customer information is otherwise
provided. The domains are listed in various DNSxLs hosted by the ESP which are
easily queryable via DNS lookups. Each DNSxL conveys a specific meaning
(typically leaning more in the "allow" than "block" part of the spectrum), as
defined by the ESP. Mail receiving organizations may choose to incorporate
querying these DNSxL lookups into their mail filtering and un-modification
algorithms as they deem appropriate. I reference un-modification because I
think it can be adapted to fit with Wei's Tolerating Mailing-List Changes
draft, and expand the scope to "Tolerating Modifications and
Non-Authenticatable Mail From Reputable Intermediaries and Sending Providers"
> What might a report look like?
I guess the format and the information in DMARC reports would be a good place
to start the discussion, with some tweaks for forward signature info, and
privacy and DOS considerations. The typical once/day timeliness of DMARC
reports is probably not fast enough to stop an active replay, but good enough
for an ESP to remove the bad actor and introspect about how to detect and
prevent future occurrences.
Jesse
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
