Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

["Murray S. Kucherawy" <[e-mail]>]

On Sat, Aug 12, 2023 at 12:31 PM Steffen Nurpmeso <[e-mail]>
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".
>
> [...]
>

If I'm able to follow your "subsignatures" idea, this is a different
approach to what is ultimately the same method proposed in my draft(s)*,
namely binding the signature to the envelope recipient list.  It has the
same limitations, such as inability to tolerate any sort of envelope
rewriting, which includes simple aliasing/forwarding, and splitting of the
envelope if it had more than one recipient.

It seems to me that the notion of a subsignature per receiving domain
doesn't scale well to a single message that goes to hundreds or thousands
of domains, and a subsignature per recipient doesn't scale well to a single
message that goes to hundreds or thousands of recipients irrespective of
their domains.  In either case, it won't be long before we run into MTA
limitationsThe optimal case is generation of a single message, and
corresponding signatures, per recipient, but that means we fail to take
advantage of the "common factoring" feature of SMTP, with unknown aggregate
costs.  It's been argued that most email these days is single-recipient
anyway, so maybe some of this isn't a big deal, but we should collect some
data about that before proceeding with that as a general assumption.

You could sign a message such that it binds the message to a particular
sender domain and receiver domain, but in a target-rich environment like
Gmail or Yahoo, all I need is one such pair and I can replay to a pretty
huge number of users.

Lastly, I suggest that we've wandered pretty far afield from talking about
the problem statement document.

-MSK, participating

[*] I discovered that it seems we went through this exercise once before
about seven years ago, and the same idea came up then as now:
https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-rcpts-01