On Wed, Aug 9, 2023 at 9:07 AM Steffen Nurpmeso <stef...@sdaoden.eu> wrote:
> All these problems are long known to (and "solved" by) the OpenPGP > (and S/MIME) communities, no? > In OpenPGP you can either encrypt-to a single or many recipients. > (With at least GnuPG you can also "hide" those recipients: > > ‐‐hidden‐recipient name > ‐R Encrypt for user ID name, but hide the key ID of this > user’s > key. This option helps to hide the receiver of the message > and > is a limited countermeasure against traffic analysis. If > this > option or ‐‐recipient is not specified, GnuPG asks for the > user > ID unless ‐‐default‐recipient is given. > > ). (Also GnuPG just recently introduced a "company-super-key" like > thing, as it seems many work groups etc. need to encrypt to each > member, and then the communication must be archived, with the > possibility to decrypt years later. But, eh, only for > completeness.) > There aren't per-user DKIM keys. I mean, there could be, but that's not how it's designed or maintained. So the best you could do is per-recipient-domain signatures, but I don't think that solves much: If I launch a replay attack from gmail.com at yahoo.com, or even simply back at gmail.com, I can still hit a large number of recipients without needing an array of signatures or revealing that replay is occurring. Isn't this discussion about Bcc: off-topic and solely RFC 5322? > I have never seen a MUA implementation which does anything else > but "throwing recipients into" To:/Cc:/Bcc:. And then there is > "undisclosed-recipients", where anything is consciously not part > of IMF/5322, but only in SMTP/5321, but still per-recipient DKIM > should work out, then. > "Bcc" came up in the context of supporting DARA as a solution to the replay problem, I believe. > It seems to me that adding a per-recipient DKIM "sub-signature" > can be accomplished very cheaply, and "scales to > super-parallelism". > If by that you mean a distinct signing key per user, I don't think this scales. That's not because DKIM can't handle it, but because I don't think large operators like Gmail or Yahoo want to maintain millions of public keys in their DNS. -MSK, participating
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
