On Wed 16/Aug/2023 19:48:30 +0200 Murray S. Kucherawy wrote:
On Wed, Aug 16, 2023 at 10:25 AM Alessandro Vesely <ves...@tana.it> wrote:
On Wed 16/Aug/2023 15:26:43 +0200 Laura Atkins wrote:
On 16 Aug 2023, at 12:59, Alessandro Vesely <ves...@tana.it> wrote:
On Wed 16/Aug/2023 11:17:50 +0200 Laura Atkins wrote:
On 16 Aug 2023, at 09:57, Alessandro Vesely <ves...@tana.it> wrote:
How about enacting common sense rules such as Never sign anything
without reading the small print? In the same way that users agree to any
Terms & Conditions without reading, domains sign any mail their users send
without knowing. Decadent practices, aren't they?
Can you expand on this? I’m not sure I understand how reading the
content will fix the problem. Spam is an issue of volume mostly.
Avoiding to /sign without knowing/ could perhaps partially solve the
problem. Reading the content was just for comparison with signing
agreements.
Without knowing what, though? I am just not understanding what
Sorry, I meant without knowing who is the author.
According to RFC 6373, "DKIM separates the question of the identity of
the Signer of the message from the purported author of the message." Yet,
an open signer is for DKIM the equivalent of what an open relay is for
SPF. >
I'm not convinced advice is necessary here. Do you really need signs in
banks that say "Don't put your signature on random financial documents"? I
have to believe that people understand what it means to sign something, and
why they shouldn't do that.
Well, when banks don't do that, they're in bad faith. Consider, for example,
derivative financial contracts conceived so that nobody is able to read them
—banks don't even try to print them. Decadent practices.
We're already saying that a valid DKIM signature means the signer takes
"some" responsibility for the message. Saying "Don't sign random things"
seems redundant to me; it presumes the first sentence is somehow deficient
or hard to understand. Is that what you're claiming?
Domains cannot "read" the messages they sign. Some MPs may have wonderful
anti-spam filters, but that's still not the same as reading and signing an
agreement. We need to dismantle the agreement metaphor a bit.
If this reduces to "Don't sign spam," then I don't think we need to say
that. Wei or Emmanual can confirm to be sure, but I'm pretty certain
Google doesn't sign absolutely anything, in the sense that if you connect
to them, authenticate, and then start spraying spam, it's going to get
detected and disallowed somehow.
The problem occurs when someone finds a way through the spam filters. I
worked for a spam filtering company for a few years, but it doesn't take
such direct experience to realize that it's an arms race: Attackers are
trying to figure out what won't get caught and then exploiting that until
the service provider catches up; rinse, repeat. That gap will always come
and go, and to assert that the gap should never ever be there and the
service provider should be ashamed of itself if it ever occurs seems
unrealistic to me.
On the other hand, there are domains which blindly sign anything their users
write, enacting only minimal limits to prevent abuse in case of compromised
credentials. They can afford doing so because, for example, users are
employees and are known in person. Do such domains experience replay attacks?
What I'm trying to address is the relationship between users and mailbox
providers. Free MPs want anyone to be able to create a free account, and that
was at the root of their success. When domain authentication arrived, they
considered that /all/ messages from their domain must be authenticated. DMARC
reporting is specifically aimed at such goal.
But domain authentication was conceived as a coarse-grained form of
authentication where the responsibility that a domain claims is meaningful as
long as membership to that domain qualifies an author in some way.
The arms race you refer is the result of indiscriminately accepting all users.
A small percentage of them are bad actors, but cannot be identified because, in
general, the real IDs of users is not ascertained. At what point does claiming
responsibility for non-ascertained entities results in decadent practices?
To repeat my questions, then, would limiting (qualified) DKIM signatures to
verified accounts diminish replay attacks by any amount? Is this kind of
solution acceptable?
Sure, you should only sign things if you have reason to believe the source
and the content are such that you're willing to attach your good name to
it. Whether that's authentication of the submitter or scanning of the
content, or both, or other checks, is entirely up to you. But by saying
"you take some responsibility" for messages, I think we're already saying
that and don't need to repeat ourselves.
There is no equivalence between authenticating subscribers and scanning what
they write. Both tasks need human intelligence, but the former doesn't have to
be done on each message. Scanning w/o intelligence is only heuristic and
relies heavily on volume limits, which is where replay attacks get away with it.
I'm not the only one saying that DKIM allows replay attacks by design. I'm
looking for solutions that don't try to modify DKIM, if they're admissible.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
