Hello.
Jesse Thompson wrote in
<[email protected]>:
|On Fri, Aug 11, 2023, at 4:34 PM, Steffen Nurpmeso wrote:
|> Jesse Thompson wrote
|> The aspect of DKIM-subsignatures revealing Bcc: presence (of 1+
|> recipients of a domain) if a Bcc: recipient replies to a message
|> that Murray Kucherawy adduced i obviously have not fully addressed
|> with my response.
|
|If I reply to a message that contains no Bcc header I am revealing \
|the fact that I received the message. I don't understand this issue. \
So it is. If you are the member of the blind carbon copy list,
noone will know you have received the message until you reveal
this yourself by replying to it.
It is just that *if* per-recipient-host DKIM subsignatures would
be used those subsignatures *could* be a vivid part of the
message. And despite all the trace fields which do exist they
would add onto "that privacy issue".
|Are you conflating the issue with forwarding?
No matter over how many corners you got in possession of the mail
which' ownership you have revealed by replying to it ---
if DKIM subsignatures (for Bcc: recipients only) would be stripped
as part of the DKIM contract in between sender MTA and recipient
MTA DKIM does not add onto that privacy problem. (Trace fields
etc continue to exist.)
|> DKIM is meant to be automated in between machines.
|> Today it pledges one side, the sender one, but with this, if we
|> throw in the american style we could call it "smart" or
|> "reflective" DKIM, the pledge is extended to be in between sender
|> and receiver.
|
|This is an argument for removing DKIM signatures for any submitted \
|messages, so the ESP can add their own signature which includes the \
|RCPT TO or signed Bcc. The main blocker for ESPs doing that is their \
|customers may require to apply their own signatures instead of delegating \
|their domain's keys to the ESP. So, ESPs would need to only allow that \
|for trusted customers and spammers will try to appear trusted and/or \
|continue to exploit compromised credentials of trusted customers.
Wait, wait, wait. DKIM would continue to work just the same as it
does today. The only difference would be that the sending MTA('s
DKIM creating eg milter) injects additional DKIM subsignatures,
and it does so only for those domains which announce via (DNSSEC
secured) DNS that their email infrastructure is prepared to handle
them. Just like today there is a _domainkey DNS entry.
The added security that locks out, or immediately reveals
spammers, would be that the updated software of host X can
cryptographically verify that the message addresses only those
recipients on host X for which it was meant.
Man-in-the-middle could only repeat sending the same mail over and
over again, including Bcc: recipients, any other spammer could
only resend to To: and Cc: members.
DKIM replay to an extended set of recipients is no longer
possible, which i think was Dave Crocker's idea.
Duplicate messages to the same set of recipients can be detected.
The only remaining option spammers would have is stripping DKIM
entirely, as you say.
You therefore suggest that recipient hosts check via (DNSSEC
secured) DNS whether the sender uses DKIM?
Of course the meaning of announcing the "new" "dkim-encrypt"
domainkey via DNS could be extended to mean "any mail sent from
this host can be verified with DKIM".
It feel a bit helpless against "compromised credentials of trusted
customers".
I must admit i do not understand your "delegating domain keys"
argument; DKIM keys work per DNS host name, and mail service
providers that serve email for customers have to have access to
the DKIM key of their customers, already today.
By the way i am a bit troubled by the ESP you mention, for me ESP
translates (even after web search) to Encapsulating Security
Payload of RFC 430[13] aka the Ken05a reference of RFC 4301. But
SMTP continues "not to be Barbie", it is still possible to use
non-encrypted channels for SMTP.
This boils down to:
- Hosts publish via DNS a DKIM-subsignature creation key.
DKIM DNS is long established, DNS time-to-live allows for
local caching, minimizing network usage. Key is small.
Key presence also signals that emails from this host contain
DKIM signatures and subsignatures, allowing classification of
messages without DKIM as spam.
- DKIM-Signature: the same as ever except that it flags presence
of subsignatures (as necessary).
- DKIM-Subsignature: is generated for all recipient hosts which
publish the DNS key as above.
Fixates public To: and Cc: recipients of a host to the above
key, plus the checksum of the normal DKIM-Signature.
Recipient host name (X) is not encrypted with key of host X to
allow fast matching; decryption then reveals list of
recipients etc.
DKIM-Subsignature: wx.yz.com; ENCRYPTED-BASE64-PAYLOAD
- DKIM-Bsubsignature: like Subsignature:, but for private Bcc:
recipients of host X. Temporary contract data.
Never occurs as part of a message: private Bcc: recipients
must be sent a forked message, extended by this host specific
header. The header MUST be stripped by the recipient host
SMTP processing pipeline before handing over the message to
actual delivery.
+ Existing SMTP infrastructure compatible.
+ Existing DKIM continues to function.
(RFC 6376, section 3.6.1. says for t= "Unrecognized flags MUST
be ignored". Maybe "r" for "replay" or "m" for "mutual"
(security) could be used.)
+ To upgrade, install updated DKIM milter/filter etc, and
publish DNS record.
+ Processing cost unremarkable.
+ Additional encryption necessities parallelizable.
There is one problem: messages cannot be resend "as-is". Maybe
this is what you mean. Such a message "is locked". You need to
create a new Message-ID: aka envelope etc. to be able to send it
to other recipients, at least to other recipients on hosts for
which a B?Subsignature: is included.
Ciao, and a nice Sunday i wish.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
