On 3/21/23 8:01 PM, Murray S. Kucherawy wrote:
There was one prior answer to this. Here's another.
There's a claim here that the problem statement(s) is/are too vague.
I'm a little worried that tightening up the problem definition along
these 20 vectors will give us such a tight problem statement that any
solution is so targeted as to be of limited value. The sweet spot
we're looking for probably lies somewhere in between.
I wasn't intending for these to necessarily be inserted verbatim, but
more to create a narrative of what is known and what is not known. I
suspect that quite a lot is known even if it may not be public. It's
rather useless to consider solutions that are known to not work or be
insufficient, so adding them to the problem statement in enough
specificity seems like a good way to stop going down rat holes later.
On Fri, Feb 17, 2023 at 11:11 AM Michael Thomas <m...@mtcc.com> wrote:
I've said in multiple threads that the current problem both in the
charter and the problem draft are far too vague for us to address.
Here are some from me at least:
1. Who are the victims? Just bulk senders? Are the bulk senders
signing using their domain?
In my view, there are two: The receiver of the unwanted spam (that
might not otherwise have been delivered), and the owner of the domain
whose signature got replayed as it might now suffer a degraded reputation.
But is, say, gmail or another large mailbox provider subject to the
signing part of the attack, or is it mainly bulk senders? Also: I assume
that enterprise, etc is not really affected by this. The current problem
draft is pretty vague about who suffers from replay attacks and thus who
should care about it. Also: reputation begs the question of *whose*
reputation. If a bulk sender uses delegated keys from some other domain,
it becomes the other domain's problem not the bulk sender.
1. Do senders filter outbound traffic for spam?
I think it's safe to assume that the case we're most interested in
does do this, but it seems to me that irrespective of the answer, the
attack is working.
The reason I ask is actually that if they filter outbound and they are
seeing spam from an account, that is obviously suspicious. Doubly so for
new accounts.
1. What are the characteristics of the spammer wrt to the sending
domain? Are they brand new accounts or established ones?
This one I don't have a guess about. I would say "either". Does this
need to be known, or does it need to constrain the problem definition?
Insofar as the output of the wg is to create a BCP instead of a protocol
change, yes we'd need to know what is being done to prevent it currently.
1. Do sending domains keep track of users who are sending spam in
the eyes of their filters? Do they correlate that with other
characteristics of their users such as freshness?
Also "either".
1. Do senders pay any attention to the To domain?
I can't imagine this being valuable signal, given the additional use
of various other address fields.
1. Do receivers pay attention to the To domain(s)?
Same.
In the case of a bulk sender, crafting a message to new or likely
disposable domain might be considered suspicious. It is the essence of
the attack, after all. If those senders can police that, that makes the
attack all the more difficult to pull off. In the end, there is a
business relationship between bulk senders and the spammer abusing them.
That gives them more control than say a mailbox provider. As in: why are
you sending to no-name domain from a bulk sender?
1. Does the To domain spammers use remain more or less static, or
do they mutate at a high rate?
The "To" field, or the RCPT TO(s) in the envelope? It seems like the
To field (if signed) never changes, or it's whatever the spammer wants
it to be if it's not signed. In the latter case, it's easy to make
"To" and RCPT TO match, thwarting that check.
The 822.To.
Do we need to know this to define the problem space?
Again, BCP, BCP, BCP.
1. Can filters be adjusted at a more fine grain in the face of
different conditions? That is, accept a higher false positive rate
in certain conditions?
This seems to me to be part of the answer we might provide rather than
part of the problem definition.
Again, we either find out now or we are doomed to ask about it later.
Part of the meta problem with this wg is what is available in public vs.
what is proprietary or not for public consumption.
1. Do receivers use things like unsigned Subject or To or other
tell-tale fields as signs of a bulk replay?
I don't think they've ever been specifically associated with replay,
but an unsigned Subject was held up even in the early DKIM days as the
sort of thing about which a receiver might exercise its discretion to
invalidate a signature. The Authentication-Results RFC introduced the
term "acceptable to the verifier" around this sort of decision tree.
I frankly don't know why To, CC, Subject weren't required to be signed.
I don't even remember any discussion of it, but it's been a long time.
But signing/oversigning is obvious BCP fodder since the protocol leaves
this as an attack vector.
1. What percent of incoming email to a mailbox is through
resenders and of that what percent resign?
By "resign" you mean something that has signatures from two domains,
correct? If so, how could one tell whether the originating operator
did or did not attach one or more of them?
As in a mailing list makes a breaking change but resigns it with its own
domain. The mailing could obviously sign their auth-res which if they
have a good reputation the receiver might trust as a reasonable proxy.
Again, a lot of my questions are aimed at the meta-problem of what can
actually be achieved here if questions like these can't be answeredin
public.
Mike
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
