On November 12, 2022 6:46:13 PM UTC, Wei Chuang
<[email protected]> wrote:
>On Fri, Nov 11, 2022 at 9:31 PM Scott Kitterman <[email protected]>
>wrote:
>
>> On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote:
>> > Sorry I'm late to this thread.
>> >
>> > On Thu, Nov 10, 2022 at 4:42 AM Scott Kitterman <[email protected]>
>> >
>> > wrote:
>> > > I agree that we don't want too much detail in the charter about the
>> > > technical
>> > > nature of the problem, but I would like to understand it in more
>> detail in
>> > > order to better assess the appropriateness of what is there.
>> > >
>> > > If a domain is signing spam and their reputation suffers as a result,
>> > > isn't
>> > > that the system working as designed?
>> > >
>> > > I would like to understand what is the technical characteristic of
>> these
>> > > messages that is distinct from the non-bad ones. As far as I can tell
>> > > (and
>> > > this isn't the first time I've run across these discussions), there
>> isn't
>> > > one.
>> > > If that's the case, then I don't think there's an actual technical
>> > > solution to
>> > > this problem.
>> >
>> > The slides
>> > <
>> https://datatracker.ietf.org/meeting/115/materials/slides-115-dispatch-dkim
>> > -replay-problem-and-possible-solutions> at Dispatch and the problem
>> > statement draft
>> > <https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/>
>> help
>> > describe the DKIM replay problem.
>>
>> I think this draft is very useful. I think it supports my contention that
>> this problem is not technically distinguishable from legitimate mail flows.
>>
>> > There are some things that we could target at a technical level. We
>> > probably would look for characteristics in the typical attack flow i.e.
>> > After having a spammy message signed, the spammer typically copies a
>> > message from the inbox, and then broadcasts it with a high degree of
>> > amplification. We could look for
>> >
>> > - Messages that are sent to recipients that are not intended by the
>> > original sender or the forwarder
>> > - Messages may be viewed as traversing a path defined by the original
>> > sender and forwarder. Messages taken from that intended path could
>> be
>> > replay
>> > - A variation is: messages that are taken from the inbox and then
>> resent
>> > - Count the signatures seen and filter by count
>>
>> I think that between the draft and the discussion so far there are a few
>> classes of potential solutions:
>>
>> 1. Signers have taken responsibility for the message when they signed it,
>> so
>> they get to live with the consequences of having done so (for this
>> purpose, I
>> think the "message" is the signed content of the message). No standards
>> action or changes required to DKIM, except maybe modernizing header field
>> signing/over-signing recommendations to make replay at least a little more
>> difficult.
>>
>> 2. Introduce changes that break existing indirect mail flows. Standards
>> actions needed. Senders and receivers both need to make changes.
>> Standards
>> actions needed. If we go down this path, would it be more honest just to
>> declare indirect mail flows obsolete/deprecated (based on the prevalence
>> of
>> >From re-writing on mailing lists, common practice may be headed this way
>> already due to DMARC).
>>
>> 3. Changes that modify expectations for legitimate indirect mail flows
>> that
>> illegitimate indirect mail flows such as replay attacks will have
>> difficulty
>> copying. These require changes by senders, indirect mail processors (e.g.
>> mailing list providers and forwarders), and receivers. Unlikely to be
>> effective until widely implemented.
>
>
>> Are there more?
>>
>
>A way of bridging this, particularly for approach 3, is to use legacy
>authentication in addition to the replay resistant technique. Use the
>replay resistant technique when available in preference to DKIM for DMARC
>and reputation systems, but have it available to fall back to. A follow on
>consideration then is why would anyone adopt the new replay resistant
>technique. Presumably there would be deliverability incentives for senders
>and forwarders to adopt the replay resistant technique (due to the negative
>reputation effects DKIM replay has) and for receivers to avoid
>escalations. In any case, I think the above categorization is pretty
>reasonable.
>
>
>> > > Once work is chartered in the IETF, it tends to get a certain momentum
>> > > toward
>> > > producing a result. Before agreeing that we have a charter to solve a
>> > > problem, I'd like to understand we have a problem that can be solved,
>> even
>> > > though that requires a bit of discussion at a more detailed level than
>> > > what
>> > > eventually goes in the charter.
>> > >
>> > > Leaving aside algorithms and processes for a moment, could someone
>> > > describe
>> > > how an technically proficient human would examine one of these messages
>> > > and
>> > > determine they are "bad"?
>> >
>> > What I've seen is that the Received header shows the delivery of the
>> > message to the initial recipient, followed by a new set of Received
>> headers
>> > that shows that the message has been resent. Sometimes the spammer
>> leaves
>> > behind other clues like duplicate headers like multiple Date, Message-id
>> or
>> > Subject headers.
>>
>> None of these other clues need anything from DKIM to detect, although over
>> signing such fields may help (no RFC is needed for this, senders can just
>> do
>> it, if it's useful).
>>
>
>Received headers are generally not DKIM signed and spammers have
>stripped/probably modified them. Another problem is that while a human can
>interpret the domain names, IP and other information present there in the
>headers, the non-standard naming and format variations means that it's not
>suitable as a machine readable signal in my opinion.
I don't think there's any point in pursuing solutions that require a human to
read/understand anything about header fields.
Having reviewed the proposals again, it seems like anything that actively makes
replays harder without adding additional indirect mail flow failures amounts to
a plan to document the flow of the email to provide additional signal for
receivers to understand what's been replayed versus what's a normal indirect
flow.
I'm inclined to think that instead of specifying specific drafts to consider,
the charter should point to the problem statement draft instead.
Scott K
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
