On 8/20/2025 12:10 PM, John R. Levine wrote:
On Wed, 20 Aug 2025, Dave Crocker wrote:
Client signing was clearly out of the question since there's no
reasonable way to manage the signing keys, so if they're not going
to sign it makes sense for them not to verify either.
I do not understand what the key management problem is that you are
referring to. I am guessing the issue has to do with multiple users
being able to access the same private key.
But, of course, there is nothing to prevent each user from having a
different private key, tied to different public key, tied to a
different selector. That sort of administrative freedom was one of
the reasons for have selectors.
To put it mildly, that doesn't scale.
And since I was not making an operational recommendation, that doesn't
matter. My point was the DKIM, as technology, permits it.
The distinction between choices in 'architecture' vs choices in
'implementation' vs. choices in 'operation' are important. But mostly
not distinguished in these discussions.
The largest zone file I know is .COM with about 300 million records,
not counting DNSSEC signatures. A key per user at a large site like
Gmail or Outlook would be an order of magnitude larger.
Note thatt 'selector' does not need to be a flat namespace.
selector = sub-domain *( "." sub-domain )
So it's possible to have a sub-tree of user keys. Again, I'm not
recommending this, merely noting it is possible.
Back when there was general discussion of personal domain names -- this
was not part of DKIM issues, per se -- the systemic concern was for
disrupting DNS caches. There was, of course, also a concern for the
administrative hassle of creating the per-user domains. For most
operations, yes, that has serious challenges. For a major platform, I
assume it does not, given everything else they can and do do at scale.
You could share keys among users, but then if a user's account is
cancelled or his key is compromised, you have to rekey everyone
sharing the key and that doesn't scale very well either.
No, in practical terms, you can't share keys. Arguably not even a
2-person group...
Also, by that point we had realized that spam filtering works a lot
better in the MTA than in the MUA. It can look at lots of mail at
once, not just mail to one user, and have shared dynamically updated
criteria. You can still have per-user criteria, but they're applied
in the MTA so, among other things, all of the user's MUAs see the
same results.
Except there is nothing preventing having UAs share assessment data
with a common analysis engine.
Hypothetically I suppose that is true, but if there's a common
analysis engine, it might as well do the filtering so the MUAs don't
have to download copies of all the spam.
Not if the message is end-to-end encrypted and only the recipient can
decrypt it...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
