On Tue, Aug 8, 2023, at 5:18 AM, Laura Atkins wrote:
>> On 6 Aug 2023, at 19:07, Jesse Thompson <[email protected]> wrote:
>>
>> On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote:
>>>> On 5 Aug 2023, at 02:43, Jesse Thompson <[email protected]> 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?
>
> I agree wholeheartedly. I just wanted to make it clear for the record that
> this isn’t an issue of the signer knowingly signing spam and “deserving” any
> reputation problems.
>
>> 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’ll have to read that more fully, but a brief read through seems to indicate
> this isn’t the solution to the replay problem. To whit:
>
> "6. Security Considerations
> It opens up a variety of obvious replay attacks that may or may not be
> important depending on both the selection of target domains for messages to
> be forwarded, and the behavior of forwarders that receive messages with
> conditional signatures.”
It doesn't stop replay. It allows for fine-grained identification of mail
streams as well as an opportunity for invalidation of individual mail streams.
> Also, I’m not sure how it will work on mail that isn’t expected to be
> forwarded.
I wasn't intending to solve the forwarding problem. I'm a proponent of munging
(not sure if you want to have that debate here instead of the other list). I am
trying to keep an open mind on that. I am of increasingly of the opinion that
the challenges for mailing lists are not very different than the challenges for
ESPs, so the solutions might start to converge.
>>>> 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.
>
> Are you suggesting individual signatures for each recipient domain?
I wasn't thinking of that specifically, but potentially. I was thinking of
individual signatures describing the context in which the message was submitted.
>
>> 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"
>
> I’m not sure asking for more work from third parties (the DNSxL maintainers)
> is a viable long term solution. We know there are spam gangs that focus on
> one or two domains. Those domains may consume DNSxL data, but do they send
> data back to the DNSxL?
I meant using DNSxLs as the protocol for DKIM signers to convey information
that describes the context in which the message was signed. Not to be used as a
traditional DNSBL. Whether signers use third parties to host DNSxLs is their
choice.
>
>>> 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.
>
> Yeah, I think that’s the real issue here. As I understand it the attacks are
> fast - sometimes a few hours from the original message and the replay with
> everything being over in <24 hours. If my understanding is correct anything
> we do needs to be handled in a time sensitive manner.
Regardless of whether an active attack mechanism is needed, DKIM signers would
still benefit from knowing the circumstances in which signatures are failing or
being misused. Without visibility they will not be able to contribute to the
solution.
Jesse
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
