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

[Steffen Nurpmeso <[e-mail]>]

Hello Mr. Kucheraway.

Murray S. Kucherawy wrote in
 <[e-mail]>:
 |On Sat, Aug 12, 2023 at 12:31 PM Steffen Nurpmeso <[e-mail]>
 |wrote:
  ...

[Bringing back some quotes]
  ||[e-mail]
  || |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
  
  |Murray S. Kucherawy
  |"Bcc" came up in the context of supporting DARA as a solution
  |to the replay problem, I believe.

  ...
 |>|> 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)*,

Oh!  Thank you!!  I did not know about this.
But yes, it has been seven years, and it seems to be a very
different approach.
(For example i never even thought about doing normalization of the
local part, i would simply throw that in, because the address is
used as-is within RCPT-TO:<> anyway, so they shall not quiver.)

 |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

But isn't this broken as of today already?

For example in this spring i had a short communication with
a FreeBSD developer, which worked last year, but this year i got
bounces.  After contacting their postmaster (actually philip@,
Iceland government member if i am informed correctly, aka Viking!)
he came back with "This works as intended" --- they simply forward
[e-mail] to real addresses, @gmail.com in this case.

..Because i have had, since 2015, a SPF record with -all.  But
"suddenly" Google seems to think it has to truly implement it,
somewhen in between.  Isn't that an insolence?

   |> It never happened in the past, and i have this policy since end of
   |> 2015.  Changing to ~all could be done, i do not know if Google
   |> gets that.
   |
   |Google may have been ignoring your -all until recently.

I pointed philip@ to postsrsd [1] (i am tracking it ever since),
which seems to have been invented to support this kind of problem.
Ie it does Sender Rewriting Scheme (SRS).
It creates temporary things to make email flow work regardless.
(I do not know whether freebsd.org started using it.)

I had to change my SPF record to ~all.
What is a SPF record with ~all worth.
I can almost throw this down the trashbin.

I want to point out that i personally, even though i am not
a kernel developer (!), get fearful whenever i see that static
timeouts are used to circumvent problems of asynchronous events.
Really!
For example i have a Japanese mailing-list member who seems to
live on the countryside, then go to somewhere with internet access
and start working, and *then* his domain name can receive email.

Static timeouts on asynchronous events are evil.
In fact, they are a sign of helplessnes.

This i wanted to point out on this list once timeouts came up.
SRS strives me as helpless hand waving.

Also on this list, someone said something like "i really do not
know how this can work with mailing-lists".

The conclusion is it does not work today.

  [1] https://github.com/roehling/postsrsd.git

 |envelope if it had more than one recipient.

Why does it not work with envelope rewriting?  Why do you want to
rewrite the envelope?  What do you mean by "splitting of the
envelope"?

Isn't it quite the opposite?  _Today_ it is broken, and "does not
work" (without myriads of configuration, and bells, and whistles;
and bad hacks and mutilations and adulterations).
With an, well, improved DKIM there is light on the horizon that
email can just work again, as it did for so long.
And that would be so fine.

By the way _nothing_ changes with this work-out-run of
subsignatures of mine last week, _unless_ you upgrade your own
system to take part.  (This is different to your draft.)

I mean i do not know.
In my thinking SPF is only an aid against stolen domain keys, no?
If recipients can verify the _original_ message against my domain
key, i am totally fine if they received it from some spammer
domain (however it got there).
That is, i do use S/MIME.  I once in a while use PGP (in maybe two
years much more often than today).
I do not care which dove carried that letter, the receiver will be
able to verify i wrote it.  Let aside key stealing.
The very same is true for DKIM, especially for the hypothetically
"then".

So in the above example, @freebsd.org could create their own DKIM
plus RCPT-TO:<> subsignature and then forward to the actual
address on @gmail.com.  I would remove my SPF record.

 |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

Hm.  I hear Dave Crocker say "email is I/O bound work" (he often
does).

Dependent on the infrastructure you may be right that costs
increase: taking out any RCPT-TO:<> that is not part
of To: or Cc: is cheap, but the same message must then be sent to
each RCPT-TO:<..@HOST> by itself.  I think milters may be the
hardest, the DKIM i want to write for postfix (somewhen) was
always planned as a postfix filter that speaks SMTP, for that it
seems to be pretty straightforward and easy (as in, receive one
message, sent back one to multiple ones).  I do not know, maybe
milters must collect all the data to a temporary file, and then
send that out.  (I have never actually written a milter, i do not
like the protocol.)  But .. *i* could imagine it can be done very
cheaply on a wholistic implementation, like a processing pipeline
working on objects, or such.

Regarding crypto...  Actually i think a modern box with a modern
OpenSSL (or other crypto library) has so many hardware
optimization possibilies for ciphers etc that this should not be
_that_ remarkable.  It is also that you only need to encrypt a few
bytes per domain, only the recipient's local names, and the
checksum of the normal DKIM-Signature:.  Even my elder laptop can
do two millions of "openssl speed -evp sha256" of size 64, for
example.  And a thousand domains with recipients "superuser
steffen" plus checksum string do not exceed 64 KB of storage.

 |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

..no..  MTA limitations because of these subsignatures?  No, that
i do not follow.  Compare this little thing with RBL DNS lookups,
or Bayes spam filtering.  My own little four-five year old
bogofilter LMDB Bayes wordlist is 478 MB (dumped and xz(1)
compressed it is 86820889 bytes).  Who knows how large a real one.

 |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

Yes, unfortunately.  Per-recipient would be best.
But per-domain is ok, is it?  If all local names are available.

 |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 save a lot by doing DKIM-only of course.  I think you are
exaggerating a bit.  I for myself think quite the opposite,
especially if, say, an actual DKIM implementation simply walks
over in-memory objects, and sending out a mail is a matter of
dump-to-wire.

The first question is of course whether it is worth it.
I think keeping any non-To: and non-Cc: RCPT-TO:<> out of
visibility is.  (Mind you, OpenSSH is currently hardening itself
against [1], .. i persnally would simply start ticking and run for
some time after the last keypress, that needs no floating-point
arithmetic, but i am an anti-mathematician :)

  [1] https://people.eecs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf

 |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.

Here you do not refer to the final variant of my "proposal" of
last week, which includes Jesse Thompson's idea (as i understood
it) that presence of the new "dkim-encrypt" in DNS announces that
all mails of this domain are DKIM-signed.
Man-in-the-middle can replay only to the very same recipients, all
others only to To: and Cc: recipients.  (Unless i am mistaken.)

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

Even your draft from 2016 mentions the "replay" problem, so
fixing the replay problem is on topic, may the problem statement
document be written after the problem is fixed.

In the end i think the proposal does much more, especially when
bundled with things like DKIM-Store:.  I think email should be
made workable again, and i see no difference in between S/MIME or
OpenPGP and DKIM instead of the "initiating person", it would be
tremendous if a cryptographically verifiable chain back to the
original message content would exist.

Granted, user-interfaces had to deal with protected (S/MIME, PGP)
aka "restored" (DKIM / M-L) headers in order to give users
opportunities to realize (modifications, etc); they could be given
hands aka options (as in "do not show me the original header of
any mail from this address [it is a mailing-list which creates
tagged Subject: lines]").  This is surely IETF off-topic.  But
anyhow, for such to happen, it must be reproducibly and securely
detectable.

 |-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

Thanks for the link.  I did not know about this draft.  It is
seven years old, and i think last week's workout has some
important improvements over the mentioned approach.

--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)