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 mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
