On Wed, Aug 9, 2023, at 3:12 PM, Murray S. Kucherawy wrote:
> 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.
I brought "Bcc" up IIRC because I was thinking about "5.1. Include the SMTP
RCPT-TO address in the DKIM signature" and this basically means that the Replay
problem is because the recipient is blind. There's already a header for blind
recipients: Bcc. Headers can be signed, hence it would be "in the signature".
Individual messages can be sent to each recipient, each with their own
signed-Bcc. Only the recipient sees their address in Bcc, so there's no privacy
concern unless the receiving server/client doesn't strip it and the message is
forwarded. I don't think DARA was on my mind, but maybe.
Any inclusion of RCPT-TO in the headers or signature is a privacy concern if
the message is forwarded, but those tend to show up in Received headers anyway.
Seems like a wash, regardless of where you put it.
I am thinking that a solution could be for an MSA to add any header (Bcc,
Forwarded-to, etc) and sign it (optionally, since the existence of the RCPT-TO
in the header is enough for receiving organizations to weed out Replays). But
the mention of PGP and S/MIME makes me realize that practice may break
legitimate submitted signed messages, including DKIM signed messages with those
headers in its signature.
If the header approach is chosen, MSAs must ensure it can't be a signed header
during message submission. MSAs accepting the signed header becomes prohibited
(if detectable) as much as "open relays" were shunned into non-existence (which
seems like an effective and transparent motivator to adoption). "if detectable"
is the main unknown in my mind. The MSA should add their own signature, which
signs the header attesting that the MSA added it, and ensure that no other
signature has that header signed. Something along those lines?
Or put the RCPT-TO address as a tag in the signature that the MSA adds. Seems
cleaner than adding normal headers and less risk of breaking prior signatures.
The downside is that the long tail of DKIM evaluators may ignore the MSA's
signature and only look at the original signature, which might be a Replay.
This is why I like Bcc. It may break things, but it breaks things not so badly,
and those minor breakages become a motivator to change.
>> 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.
I don't like the idea of distinct *keys* per recipient for those reasons, but I
do like the idea of distinct *signatures* per recipient (which is accomplished
by including RCPT-TO in the signature).
Key distinction should be aiming for more granularity at the sender level.
Domain > campaign/application > user/credential > message. Senders will be
motivated to add key granularity to the depth at which they would like
receivers to block mail they might find offensive, without blocking all mail
from their domain. Responsible senders will go to this effort to limit blast
radius for events such as credential compromise. Malicious senders may also add
this granularity to their tactics, but their malicious activity would be signed
with more granularity, so it would be easier to build verifiable algorithms to
detect malicious sending patterns.
Jesse
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
