once more i thought, because i am noone, so to say,
Steffen Nurpmeso wrote in
<20230809221343.1xkjj%[email protected]>:
|Steffen Nurpmeso wrote in
| <20230809214100.nzjxy%[email protected]>:
||Steffen Nurpmeso wrote in
|| <20230809211602.8mpmd%[email protected]>:
|||Steffen Nurpmeso wrote in
||| <20230809205628.ua41r%[email protected]>:
||||Murray S. Kucherawy wrote in
|||| <cal0qlwyjf2wyz4jbdtfptkoghpaf7gpykkcnnvhoqekv_sv...@mail.gmail.com>:
|||||On Wed, Aug 9, 2023 at 9:07 AM Steffen Nurpmeso <[email protected]> \
|||||wrote:
|| ...
|||I mean, of course DKIM could go further and encrypt those
| ...
So what i derived/thought/meant, finally, would be
- DKIM signature would flag presence of a subsignature.
That subsignature could be cryptographically linked to the
"normal" DKIM signature.
The subsignature uses the normal DKIM key, but links
recipients or at least recipient domains, as below, to the
very message that is sent.
Control flow would be:
[verify message, put RFC 7001]
|
DKIM sign message [include 7001 etc, flag DKIM sub-signature
presence]
|
prepare RFC 5321 SMTP transmission
|
- iterate recipient domains
[1] + if DNS per-domain (eg) "domainkey-encrypt" is found
. create DKIM subsignature for domain, include all
rcpt-to:<> that reside on that domain within it,
encrypted with "domainkey-encrypt".
(I guess it would be best if that would be compressed.
Security would possibly want padding this up (after
compression?), but i am not an expert.)
[SMTP send message to all recipients on domain, done]
[2] + if direct TLS connection to domain can be established
. create DKIM subsignature for domain, without recipients.
[SMTP send message to all recipients on domain, done]
- iterate over remaining recipients
[3] + create DKIM subsignature for a single rcpt-to:<> (include
it as clear-text).
[SMTP send message to one recipient]
A nice property would be that all (possible forms of) needed
sub-signatures could be generated in parallel, a task that (most
likely) would be finished long before the DNS lookups return, and
that would not require that much memory.
Then the according one would simply be picked.
I think for an integrated system the above would be
straightforward, DNS lookups are needed anyway (recipient domain
MX, maybe aditional A / AAAA), it could become usual to include
the necessary "domainkey-encrypt" for MX/xy answers.
For MTAs like postfix, exim or sendmail, where external software
like milters or filters do the DKIM work, and where each of those
isolated parts performs their own DNS lookups, things are more
expensive and complicated, though (box-)local DNS caching likely
reduces that cost. In how far a milter or filter can be
integrated to implement the decisions marked [1] and [2] above,
i do not know. Especially [2] seems unlikely for for example
postfix, but it is over a year that i read its milter and filter
documentation (once).
With the above there is a cryptographically verifiable link in
between the message, the message sender, and the recipient's
domain. Except for [2] all per-domain recipients are also
cryptographically verifiable. (But since [2] is TLS secured, it
should not really matter, as the sender MTA it is who
cryptographically links the recipients, anyhow.)
For mailing-lists it would be tremendous if DKIM would define
a DKIM-Store: or whatever header. Then any software that modifies
a message could back up those headers which it modifies (Subject:,
From:, Sender:, .. not Author:), and include this backup storage
in its own DKIM signature.
Like this receivers can re-create and verify the original message.
Again i would propose compression plus base64 for the header
bodies.
Different to today software like mailing-lists would have an
option to function as it did for several decades, while keeping
a cryptographically verifiable path all along the way.
Thank you.
--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
