Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
On Mon, Aug 14, 2023, at 11:08 AM, Dave Crocker wrote: > MTAs that are doing MTA functions are not supposed to make changes to > the content and typically they don't. I'm not designing a typical MTA. I want to design one that doesn't allow DKIM replay. Jesse ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
Jesse Thompson wrote in : |Just a quick clarification: | |You mentioned below that you didn't understand what ESP meant. I honestly \ |have a hard time unraveling the nuanced differences of Email Sending \ |Provider and MTAs, MSAs, MDAs, MTAs, "intermediary" and "forwarder"; \ |all of which an ESP could be providing as a service, depending on the \ |lens one looks at it. Sure, why not. |On Sat, Aug 12, 2023, at 2:31 PM, Steffen Nurpmeso wrote: |> The only remaining option spammers would have is stripping DKIM |> entirely, as you say. | |It's not what I was saying. If DKIM is what is used by ESPs to authentic\ |ate message submissions, and the fallback for non-DKIM signed mail \ |is to allow the submission, then certainly that is something spammers \ |would leverage. That seems like an unlikely scenario since ESPs require \ |other forms of authenticating message submission. | |I was saying that the ESP would need to strip an existing DKIM signature \ |if it is at risk of replay, and apply it's own pre-RCPT signature in \ |its place (or at least add the additional signature if it knows that \ |receivers will take both signatures into consideration and the original \ |signature is not invalidated by the message modification). What the heck are you trying to say. Sorry for that. Why "risk of replay", what shall that be? Pre-RCPT is a typo for per-RCPT? Have you read the proposal? You are fooling around. --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 Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
Alessandro Vesely wrote in <1fcef96f-27ce-2cfa-30e6-e37237088...@tana.it>: |On Sat 12/Aug/2023 21:52:13 +0200 Steffen Nurpmeso wrote: |> Alessandro Vesely wrote in >: |>> On Fri 11/Aug/2023 23:49:20 +0200 Steffen Nurpmeso wrote: |>>> Alessandro Vesely wrote in <76cede70-0558-ed62-7420-97e2e899e74f@tana.i\ |>>> t: | On Fri 11/Aug/2023 00:33:46 +0200 Steffen Nurpmeso wrote: |> Murray S. Kucherawy wrote in 8p+dkgjtw...@mail.gmail.com>: |>> On Wed, Aug 9, 2023 at 3:14 PM Steffen Nurpmeso \ |>> wrote: |>>> And couldn't it become standardized that verification results then |>>> must be included in future DKIM signatures? |>> |>> Aren't you basically describing ARC here? |> |> I am only talking DKIM. | | Indeed, including and signing Authentication-Results is one of \ | the two | relevant differences between DKIM and ARC. |>>> |>>> If in this [elided] example ietfa.amsl.com spends expensive CPU \ |>>> cycles to |>>> generate an authentication result, why is that not covered by the \ |>>> latter |>>> generated DKIM signature? |>> |>> Because A-R fields were conceived for internal consumption. Bastion |>> hosts are supposed to remove or rename existing A-R fields while \ |>> they add ... |> That is not my desire. All i would ask for is that the (older |> than ARC) DKIM signature a host generates is used to protect the |> A-R that the host generated. | |You may encounter a couple of problems signing A-Rs. First, software that |treats those fields probably removes or renames them on ingress, thereby |breaking the signature. To cope with that, you may want to slightly \ |alter the |header field name before signing it. How about Original-Authentication-\ |Results:? | |Second, in case of multiple forwards, matching an A-R (or O-A-R) with the |corresponding signature may become hazy. Trace fields are always added \ |at the |top of the header and DKIM signs from the bottom up, but is it safe \ |to rely on |that for attributing reputation? How about adding an explicit index? | |That's what I called reinventing. Ok, i personally only live in a small corner of the internet, and from the big players i practically only see Google, sometimes Microsoft. So if someone with a much broader experience says my idea is moot, then i take this for granted. --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 Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
Hello Mr. Kucheraway. Murray S. Kucherawy wrote in : |On Sat, Aug 12, 2023 at 12:31 PM Steffen Nurpmeso |wrote: ... [Bringing back some quotes] ||stef...@sdaoden.eu || |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 develo...@freebsd.org 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
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
On 8/14/2023 10:53 AM, Jon Callas wrote: The original statement from the Domain Keys folks from Yahoo was that when your bank sends an email to you, your ISP can know that, even though it's bounced through your alumni association. I'm going to press this a bit. The alumni example involves the message getting to the place it was addressed to, and is then redirected to a new address. Some folk object to calling this delivery and reposting, but the previous statement is a technically precise statement of what happens. Whatever the label given, it is not a scenario that is formally expected to survive, although in practice it usually does. It typically creates a new RCPT-TO without changing the message itself. Hence DKIM survives. But this case is fundamentally different from classic MTA-MTA transfers. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
> On Aug 13, 2023, at 20:31, Jesse Thompson wrote: > > If I understand based on my limited view of history, DKIM was designed for > authentication between two hops. Signature survival across intermediaries was > only achievable by encouraging intermediaries to not make any changes to the > message "inside the envelope" such as standards-allowed MIME re-encoding > (which, notably, prevents intermediaries from improving MIME > interoperability). I'm not the first to say it, but it was the opposite. The original statement from the Domain Keys folks from Yahoo was that when your bank sends an email to you, your ISP can know that, even though it's bounced through your alumni association. It was *specifically* a three-hop thing in the distilled elevator pitch. Remember as well that for two-hop sending, SPF was a preferred thing and there was a lot of conversation that tried to put them as competitors. We argued against that. I think it's pretty obvious that the two together are much better than either alone. Here's a vastly oversimplified case. Consider someone who runs email on a small, NATted network. Under SPF, if a spammer sends a message from any host outward, it has the same path and thus passes SPF despite being spam. DKIM is domain-to-domain authentication, not user-to-user, because user relationships are complex. Here's a not-uncommon example: Incoming email sent to info@domain goes into Alice's mailbox, via something akin to virtual users in Postfix. From time to time Alice sends a message from info@, without there being an actual user. The DKIM edge MTA signs it. That means that the mail architecture has to deal with the gap between Alice and that signing MTA. Any given setup is either a bug or a feature that they, not we, have to manage. Delegated email is a thing. Pulling in what you said above that: > [...] If DKIM is what is used by ESPs to authenticate message submissions, > and the fallback for non-DKIM signed mail is to allow the submission, then > certainly that is something spammers would leverage. That seems like an > unlikely scenario since ESPs require other forms of authenticating message > submission. I'm not sure I really understand your case here. DKIM authenticates the "administrative domain" of the sender, not the user. As noted above, the domain has to do a bunch of user management that's outside the scope of DKIM. That management can be strict (any user can only send email with their own From on it) or loose (any user can just telnet to port 25 and start sending emails from anything) or anything in between, and any decision has consequences the sysadmins have to adapt on their own. I think you're saying more or less what I was saying, but I'm not sure. As a last note, internal signatures like OpenPGP, and S/MIME, and anything else are inside the message and thus orthogonal to DKIM (and SPF). Thus, SPF is a verification of the network path. DKIM is an authentication of the sending MTA. S/MIME etc. is an authentication of the sender. Each has its own failure modes, and each has weird edge conditions and gray areas. I look at it as they go up a stack of sorts -- network -> domain -> user. Jon ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
On 8/14/2023 8:20 AM, Murray S. Kucherawy wrote: DKIM was designed to attach, with cryptographic protection, the domain name of a handling agent to the message. There's no expectation that the agent doing so asserts anything about the content of the message (i.e., "this is not spam"), nor is there any expectation that the domain signing it is the domain originating it. There's no constraint about which agent (receiver or intermediary) attempts to validate it. Since we seem to need this level of tutorial in the working group, I'll stress that everyone of the above points is not only true but is fundamental to the nature, design and intended use of DKIM. And well-phrased, IMO. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
On 8/13/2023 8:31 PM, Jesse Thompson wrote: If I understand based on my limited view of history, DKIM was designed for authentication between two hops. No. In email parlance, a hop is one SMTP transit, with relaying done by MTAs. DKIM was designed to survive from posting to delivery (for an address in a SMTP RCPT-TO command). That is, it was designed to survive classic MTA relaying. What breaks a DKIM signature -- ignoring MTAs that go beyond their remit -- is activities that take delivery and then repost. Mailing lists are the classic example, but only an example. (SPF, on the other, only survives one hop, except in very special cases.) Signature survival across intermediaries was only achievable by encouraging intermediaries to not make any changes to the message "inside the envelope" such as standards-allowed MIME re-encoding (which, notably, prevents intermediaries from improving MIME interoperability). MTAs that are doing MTA functions are not supposed to make changes to the content and typically they don't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
On Sun, Aug 13, 2023 at 8:34 PM Jesse Thompson wrote: > If I understand based on my limited view of history, DKIM was designed for > authentication between two hops. Signature survival across intermediaries > was only achievable by encouraging intermediaries to not make any changes > to the message "inside the envelope" such as standards-allowed MIME > re-encoding (which, notably, prevents intermediaries from improving MIME > interoperability) > That's not how I recall it. DKIM was designed to attach, with cryptographic protection, the domain name of a handling agent to the message. There's no expectation that the agent doing so asserts anything about the content of the message (i.e., "this is not spam"), nor is there any expectation that the domain signing it is the domain originating it. There's no constraint about which agent (receiver or intermediary) attempts to validate it. Also, there are numerous things that can happen to a message en route that could invalidate a signature. Accordingly, the only thing you know when you see a message whose signature validates is that it has not been modified since the signer signed it. The absence of a valid signature (or even of an invalid one) isn't indicative of anything. -MSK, participating ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
