[Ietf-dkim] Re: DKIM works fine
Participating only: On Mon, Apr 7, 2025 at 11:11 AM Dave Crocker wrote: > but let's be clear on my reasoning for using the name DKIM is "it is > intended to plug into the same place in the stack as DKIM does; and reuse > the key infrastructure of DKIM - meaning it will be more understandable to > MOST people if it's called DKIM2 than if it's called e.g. SEEDS (Signed > Explicit Email Destination and Source) - and that branding will assist with > getting people to convert. > > Your assertion about understandabability collides with likelihoods of > cognitive confusion. Especially since -- as the Motivation document > demonstrates and a lot of industry discussion demonstrates -- people > already tend to misunderstand what DKIM does. > > As they misunderstand DMARC, with one vendor claiming it eliminates CEO > spoofing. > > By the way, with your logic, UDP and TCP should have similar names, since > they plug into the same place in the stack. > > Or perhaps 'place in the stack' is of import to a very, very narrow > demographic, whereas the much larger demographic is a lot more likely to > more attention to basic email functionality than to abstract network > architecture placement. > I'm not following the objection here either with respect to architectural placement. As I understand where in the email flow this would occur, it would be right where DKIM is now, either instead of it or alongside it. That's probably where I would implement it given my understanding so far. So then, at least, the intent to depict it as being at that point in the handling chain seems pragmatic to me. And I don't know what else to call it until we've started to gel on both implementation and outcome. Is there a better suggestion? -MSK ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM works fine
On Wed, Apr 9, 2025 at 8:17 AM Pete Resnick wrote: > On 7 Apr 2025, at 13:11, Dave Crocker wrote: > > Bron, > > On 4/7/2025 10:53 AM, Bron Gondwana wrote: > > I buy this argument. You're quite correct, DKIM doesn't have any actual > problems. It's perfect. It does exactly what it's specified to do. > > DKIM is also insufficient for the purpose for which it's trying to be > used. And there's an argument that "the purpose of a system is what it > does". > > My point is that it is fine for what it is trying to do. It does exactly > that. That's sufficiency, not insufficiency. > > I suspect you two just talked past each other because of Bron's use of the > passive in his second paragraph. If I understand correctly, Bron is saying > that DKIM is insufficient for the purpose for which *certain anti-spam > mechanisms* are trying to use it. Or maybe for the purpose for which some > other thing is trying to use DKIM. But either way, that DKIM is sufficient > for its designed purpose, and insufficient for some other purpose. That > isn't surprising, but maybe that needs to be clear in one of the documents. > +1, I think they're both right. DKIM has proven to be a font of attractive nuisances. It would be so much better "if only we could solve replay", or "if only we could recover author signatures", or "if only we could control bounce noise", or "if only we could tie it to the From domain." These always seem to be eternally elusive, which is why they keep coming up and the proposed solutions, every iteration of which often looks remarkably like the one before it, never seem to go anywhere (or they get forced, with ugly results). I think DKIM's curse is that it is -- or was, when it first appeared -- so promising of a development that people expect it, by itself, to deliver more than it can. Maybe it got over-hyped, despite careful use of language like "take some responsibility" or "noise-free channel" or "associate a domain name", and so when some derivative capability isn't possible, it's identified as a shortcoming. Pete wants to drive to Chicago, but his fancy new car can only go as far as Calumet City. You can almost see Chicago from there, but you can't experience it. Imagine the frustration. So while I think we should continue to be crisp in how we talk about what DKIM really does, and not more, I also fully understand where people are coming from who tend to use language that identifies these absent things as defects, because it really does feel like they should be there, or at least be within our grasp. -MSK ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM works fine
On Wed 09/Apr/2025 06:15:16 +0200 Dave Crocker wrote: On 4/8/2025 5:43 AM, Alessandro Vesely wrote: Although different, DKIM2 shares a huge amount of concepts developed alongside DKIM, from the tag=value specification, to underscored domains and key distribution, to hashing and signing. The latter, signing, seems to be the most widely known feature of DKIM. "If you see DKIM-Signature: don't autoconvert." It has had a significant impact on the email ecosystem. It is from this point of view that DKIM and DKIM2 are two of a kind. tag=value is a construct that has been in use since the start of networking. An RFC733 header field is, really, tag=value. Eh, not quite. DKIM definitions are really cute, and subsequent RFCs build on them. RFC 8617, ARC, for example, doesn't even define the terms *signer* and *verifier*. Crypto hashing was around long before DKIM, too. But, sure, it is likely the new thing can share some code from the old thing. This does not make them semantically related, which the name incorrectly implies. ARC chose a different name. Then we could argue whether DKIM2 is more like ARC than DKIM, but one is the ancestor of the other two, so if protocols have a family name, it should be that. Best Ale -- ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM works fine
Alessandro Vesely wrote in <8e69637f-508c-49e6-9029-5bacdb799...@tana.it>: |On Sun 06/Apr/2025 20:56:35 +0200 Dave Crocker wrote: |> The goals for the new effort are for a very different set of services. \ |> There |> is nothing wrong with wanting those services, but really, they are \ |> not DKIM. |> |> The semantics of the new effort really are orthogonal to DKIM. (And \ |> that is |> one of the reaon the technical errors in the Motivation draft demonstrat\ |> e a |> fundamental misunderstanding, rather than being minor distractions.) |> |> One of the reasons a new effort should adopt a different name is \ |> to help people |> understand that the new effort is for something entirely different \ |> from what |> DKIM intended to do. | |AIUI, countering replay is a major semantic difference. DKIM bears \ |the concept |of identifying a domain responsible for a message regardless of which hops |forwarded the message. It overcame SPF in this regard. However, replay \ |is a |trouble for freemail providers, as it prevents them from controlling \ |the spread |of a message. As it turns out, spread can be controlled by tweaking a few |technical knobs of DKIM. The result, of course, is something different. | |Although different, DKIM2 shares a huge amount of concepts developed \ |alongside |DKIM, from the tag=value specification, to underscored domains and key |distribution, to hashing and signing. The latter, signing, seems to \ |be the |most widely known feature of DKIM. "If you see DKIM-Signature: don't |autoconvert." It has had a significant impact on the email ecosystem. \ | It is |from this point of view that DKIM and DKIM2 are two of a kind. It is bizarre that it is considered to throw away a functional protocol that is installed and in use in very large number of installations with likely grown and proven and often not simple configurations for no other purpose but to serve big egos. I do not personally concur with neither Dave Crocker nor you in that i do not see a difference. It is only that the DomainKey's coverage is extended to protect the SMTP envelope: DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message Where do you see a semantic difference when the envelope is protected additionally? (My proposal: temporarily, on mutual agreement, in the direct sender->receiver line where the envelope is anyway visible?) I even sound suggestive and manipulative. That differences, protected by signatures, come in, i welcome very much, as it will allow cryptographically verifying all modifications a message has seen, up to the original version. And that means that all DKIM signatures along the path can be verified -- this is, actually, isn't it?, for the first time, the very realization of the RFC 6376 DKIM manifest, as above: responsibility can be proven, along the path! That is a semantic difference, but in the spirit of DKIM, desired! That certain headers will always be covered, and that certain constructs are no longer valid (in my proposal that only iterates DKIM): that has proven necessary or desirable. It in parts should have been cast in standard words many years before even! That in addition the additional header fields used by both proposals are linked with sequence numbers, ie, that the "header stack" is let's say "bypassed", well, it is so la-la. I mean, it remains a stack for the "normal" header fields included in the signature itself. Here there is a semantic difference to RFC 6376, namely "6.1. Extract Signatures from the Message". The existing DKIM says: Verifiers MAY try signatures in any order they like. For example, one implementation might try the signatures in textual order, whereas another might try signatures by identities that match the contents of the From header field before trying other signatures. Verifiers MUST NOT attribute ultimate meaning to the order of multiple DKIM-Signature header fields. And that has to change, especially the another might try signatures by identities that match the contents of the From header field before trying other signatures paradigm is where i disagree with Dave Crocker, when he says "it is not DKIM that is at fault, it is DMARC". The iterated DKIM will have most hops (as far as reality really sees this in plural) only check the newest, the one with the highest sequence number. If that succeeds we are with 6376 again: a ~"single successful validation allows verification to succeed". (You know all that, of course. Just saying.) |Best |Ale |-- Greetings, and Ciao, --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
[Ietf-dkim] Re: DKIM works fine
On 7 Apr 2025, at 13:11, Dave Crocker wrote: Bron, On 4/7/2025 10:53 AM, Bron Gondwana wrote: I buy this argument. You're quite correct, DKIM doesn't have any actual problems. It's perfect. It does exactly what it's specified to do. DKIM is also insufficient for the purpose for which it's trying to be used. And there's an argument that "the purpose of a system is what it does". My point is that it is fine for what it is trying to do. It does exactly that. That's sufficiency, not insufficiency. I suspect you two just talked past each other because of Bron's use of the passive in his second paragraph. If I understand correctly, Bron is saying that DKIM is insufficient for the purpose for which *certain anti-spam mechanisms* are trying to use it. Or maybe for the purpose for which some other thing is trying to use DKIM. But either way, that DKIM is sufficient for its designed purpose, and insufficient for some other purpose. That isn't surprising, but maybe that needs to be clear in one of the documents. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM works fine
On 4/8/2025 5:43 AM, Alessandro Vesely wrote: On Sun 06/Apr/2025 20:56:35 +0200 Dave Crocker wrote: ... The semantics of the new effort really are orthogonal to DKIM. (And that is one of the reaon the technical errors in the Motivation draft demonstrate a fundamental misunderstanding, rather than being minor distractions.) ... AIUI, countering replay is a major semantic difference. DKIM bears the concept of identifying a domain responsible for a message regardless of which hops forwarded the message. It overcame SPF in this regard. However, replay is a trouble for freemail providers, as it prevents them from controlling the spread of a message. As it turns out, spread can be controlled by tweaking a few technical knobs of DKIM. The result, of course, is something different. No it cannot. It cannot control distribution. What it CAN control is use of the DKIM domain name for reputation analysis. And this is a very large difference, especially given the human factors of phishing. Also, addition of this additional control does not require modifying DKIM itself. Although different, DKIM2 shares a huge amount of concepts developed alongside DKIM, from the tag=value specification, to underscored domains and key distribution, to hashing and signing. The latter, signing, seems to be the most widely known feature of DKIM. "If you see DKIM-Signature: don't autoconvert." It has had a significant impact on the email ecosystem. It is from this point of view that DKIM and DKIM2 are two of a kind. tag=value is a construct that has been in use since the start of networking. An RFC733 header field is, really, tag=value. Crypto hashing was around long before DKIM, too. But, sure, it is likely the new thing can share some code from the old thing. This does not make them semantically related, which the name incorrectly implies. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net bluesky: @dcrocker.bsky.social mast: @dcrocker@mastodon.social ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM works fine
On Sun 06/Apr/2025 20:56:35 +0200 Dave Crocker wrote: The goals for the new effort are for a very different set of services. There is nothing wrong with wanting those services, but really, they are not DKIM. The semantics of the new effort really are orthogonal to DKIM. (And that is one of the reaon the technical errors in the Motivation draft demonstrate a fundamental misunderstanding, rather than being minor distractions.) One of the reasons a new effort should adopt a different name is to help people understand that the new effort is for something entirely different from what DKIM intended to do. AIUI, countering replay is a major semantic difference. DKIM bears the concept of identifying a domain responsible for a message regardless of which hops forwarded the message. It overcame SPF in this regard. However, replay is a trouble for freemail providers, as it prevents them from controlling the spread of a message. As it turns out, spread can be controlled by tweaking a few technical knobs of DKIM. The result, of course, is something different. Although different, DKIM2 shares a huge amount of concepts developed alongside DKIM, from the tag=value specification, to underscored domains and key distribution, to hashing and signing. The latter, signing, seems to be the most widely known feature of DKIM. "If you see DKIM-Signature: don't autoconvert." It has had a significant impact on the email ecosystem. It is from this point of view that DKIM and DKIM2 are two of a kind. Best Ale -- ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM works fine
Bron, On 4/7/2025 10:53 AM, Bron Gondwana wrote: I buy this argument. You're quite correct, DKIM doesn't have any actual problems. It's perfect. It does exactly what it's specified to do. DKIM is also insufficient for the purpose for which it's trying to be used. And there's an argument that "the purpose of a system is what it does". My point is that it is fine for what it is trying to do. It does exactly that. That's sufficiency, not insufficiency. Since you feel otherwise, perhaps you can explain in technical terms? This seems not a small point in understanding the new work, in relation to the old. What it is not so fine for is evaluating DKIM in terms of things it was not intended to do. Some of which are things the Motivation draft claims it does, but doesn't. The purpose for which DKIM is trying to be used includes the kind of reputation and "quality of email coming from X domain" tracking that pretty much every medium-to-large email operator is doing - and it insufficient for that purpose. Again, please explain in technical detail. Just trading conclusions isn't helpful to group discussion and understanding. On that basis... I'm perfectly happy to call it something completely different - I'm to a large interest more interested in the tech than the branding... ahh, name confusion doesn´t matter much. right. but let's be clear on my reasoning for using the name DKIM is "it is intended to plug into the same place in the stack as DKIM does; and reuse the key infrastructure of DKIM - meaning it will be more understandable to MOST people if it's called DKIM2 than if it's called e.g. SEEDS (Signed Explicit Email Destination and Source) - and that branding will assist with getting people to convert. Your assertion about understandabability collides with likelihoods of cognitive confusion. Especially since -- as the Motivation document demonstrates and a lot of industry discussion demonstrates -- people already tend to misunderstand what DKIM does. As they misunderstand DMARC, with one vendor claiming it eliminates CEO spoofing. By the way, with your logic, UDP and TCP should have similar names, since they plug into the same place in the stack. Or perhaps 'place in the stack' is of import to a very, very narrow demographic, whereas the much larger demographic is a lot more likely to more attention to basic email functionality than to abstract network architecture placement. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net bluesky: @dcrocker.bsky.social mast: @dcrocker@mastodon.social ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM works fine
I buy this argument. You're quite correct, DKIM doesn't have any actual problems. It's perfect. It does exactly what it's specified to do. DKIM is also insufficient for the purpose for which it's trying to be used. And there's an argument that "the purpose of a system is what it does". The purpose for which DKIM is trying to be used includes the kind of reputation and "quality of email coming from X domain" tracking that pretty much every medium-to-large email operator is doing - and it insufficient for that purpose. On that basis... On Sun, Apr 6, 2025, at 14:56, Dave Crocker wrote: > Stray, Sunday night thought for the working group to consider: > >> DKIM does not have any actual problems. Even DKIM Replay is not a DKIM >> problem. >> > Consider: > >> DKIM was designed to associate a domain name to a message, with the intent >> that no message will have that association without the 'approval' of the >> domain owner. The purpose is to create a noise-free channel, for reputation >> analysis of mail having that association. >> >> And indeed, that´s what DKIM does. >> >> Although Replay is a problem, it is not a DKIM problem, because the replayed >> messages really were associated with the domain name through regular DKIM >> authorization. (My noting that the Replay problem is an externalization of >> limitations to control and accountability of a platform's users is not meant >> as criticism, but to focus on the reality that, again, DKIM was never >> intended to deal with problems within the scope of control of the domain >> owner.) >> > The goals for the new effort are for a very different set of services. There > is nothing wrong with wanting those services, but really, they are not DKIM. > > The semantics of the new effort really are orthogonal to DKIM. (And that is > one of the reaon the technical errors in the Motivation draft demonstrate a > fundamental misunderstanding, rather than being minor distractions.) > > One of the reasons a new effort should adopt a different name is to help > people understand that the new effort is for something entirely different > from what DKIM intended to do. > I'm perfectly happy to call it something completely different - I'm to a large interest more interested in the tech than the branding... but let's be clear on my reasoning for using the name DKIM is "it is intended to plug into the same place in the stack as DKIM does; and reuse the key infrastructure of DKIM - meaning it will be more understandable to MOST people if it's called DKIM2 than if it's called e.g. SEEDS (Signed Explicit Email Destination and Source) - and that branding will assist with getting people to convert. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM works fine
> On Apr 6, 2025, at 11:57 AM, Dave Crocker wrote: > The goals for the new effort are for a very different set of services. There > is nothing wrong with wanting those services, but really, they are not DKIM. > > The semantics of the new effort really are orthogonal to DKIM. (And that is > one of the reaon the technical errors in the Motivation draft demonstrate a > fundamental misunderstanding, rather than being minor distractions.) > > One of the reasons a new effort should adopt a different name is to help > people understand that the new effort is for something entirely different > from what DKIM intended to do. > +1or humming, or whatever the current protocol for expressing agreement is.___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
