On Sun, Mar 23, 2025, 2:13 p.m. Michael Thomas <[email protected]> wrote:
> > On 3/23/25 9:47 AM, Allen Robinson wrote: > > Perhaps the issue is that two similar but different things are being > > conflated here. > > > > Is DKIM2 a new protocol? I think the answer to this is clearly yes. We > > are defining a new interaction between systems. > > That's not very clear to me for many of the reasons laid out in my > original email. > Again, I think you're equating DKIM2 being a new protocol with DKIM2 using a new header. I do not at all think these are the same. Even if we were to decide that the signature header should be reused, DKIM2 signers and verifiers aren't doing the same thing as DKIM1 signers and verifiers, and the way they are expected to interact is a new protocol. > > > > Changing the meaning of DKIM1's tags could be a reason, though it's a > > fairly weak one. Proposals from the meeting were changing h= to not > > need to list mandatory headers, and removing the need for c= by > > mandating a single canonicalization method (relaxed/relaxed, or maybe > > relaxed/simple). Even if there is an entirely new header, these > > decisions should be evaluated. > > I really don't get the need for either of those changes. If it was 20 > years ago, it might be worth considering but this has been out in the > field for like forever and I've never heard anyone complain about either > as being some sort of problem. > It's opportunistic simplification. If we're making changes other anyway, and these changes would improve the protocol, why not make them? Is it a problem that a verifier has to support two different modes for canonicalization? Not really. Is that flexibility providing much/any value? Unclear. I'm less clear on the value for h= simplification. The protocol retains the flexibility of defining additional headers so verifiers need to know how to handle the tag anyway. > > > > Simplicity for adoption is a potentially stronger reason. > > But DKIM is already widely adopted so incompatible tweaks around its > margins deserves a hefty amount of skepticism, imo. I haven't fully > thought through the implications of relaxed body wrt to the mutations > stuff, but if relaxed is required for headers anyway, isn't that > essentially the same problem? > > In any case, simplicity for adoption would be to change as little > existing software as possible. Easier to implement maybe, though you'd still need to branch on whether the message has DKIM2 signals or not. Doing that based on presence of some tags or based on the header name seems roughly equivalent. Harder to ensure that it doesn't break existing flows. Backward compatibility to the existing > code base means that all you have to implement is the new features, not > futz around with "does h= mean this, or mean some new thing?" > Well, yes, that's why we're proposing a new header. It's perfectly clear if h= means one thing in a DKIM-Signature and another thing in a DKIM2-Signature. If one wanted to reuse a DKIM1 verifier as the basis for a DKIM2 verifier (I'm leaning that way myself), generating a DKIM1-style h= out of a DKIM2 one wouldn't be particularly challenging, for example. Canonicalization is even easier since the proposal only prunes out options, you'd just tell it to do relaxed/relaxed in all cases instead of deciding based on the tag. > > DKIM2 is expected to produce signatures in situations that are not be > > producing them today. > Why? > Empirically, some forwarders and mailing lists I've seen do not generate signatures today. These systems would be required to generate a signature under DKIM2. > > By having a completely separate header, it is much easier to ensure > > that these additional signatures do not disrupt existing flows > > What does it mean to "disrupt existing flows"? A signature just says > that the signer take some responsibility for the message. Why would that > disrupt anything? > I'd define disruption as making an otherwise-acceptable email be rejected by a DKIM1 system because of the DKIM2-specific actions of a DKIM2 system. By having two independent headers, DKIM2 systems can continue to participate in DKIM1 however they do now, so DKIM1 verifiers would observe no change in the signatures they are being presented as a result of DKIM2 adoption. I agree that the simple case of adding an extra signature to a message with other passing signatures isn't likely to break anything. Adding a signature to a message where some or all of the other signatures don't pass could change the decision on whether a message is acceptable or not. > > > > because signing systems can do whatever they do for DKIM1 and add > > DKIM2 in parallel. Extra DKIM signatures are not likely to be a > > problem in flows where the message is delivered unmodified, but in > > modifying flows there may be differences in how the message is treated. > > Sure, that's seems to be the point of adding the mutations stuff. That > doesn't mean it needs a new protocol vs extending the current base. A > naive DKIM verifier would just blissfully ignore it. That seems like a > feature, not a bug. Is there some reason to believe that it's actually a > bug and if so, why? > A naive verifier would observe some number of failing signatures, as any signature prior to the modification is only going to be verifiable by undoing the declared mutations. DKIM2 systems would leave the prior DKIM2 signatures in place, but a DKIM1 system may decide it's better for deliverability to remove the failing signatures after mutating the message. > Mike > > >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
