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.
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.
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. 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?"
DKIM2 is expected to produce signatures in situations that are not be
producing them today.
Why?
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?
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?
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
