On Wed, Sep 17, 2025, at 15:43, Daniel Kahn Gillmor wrote: > Hi all-- > > Just wanted to follow up on a few points from this discussion after > chewing on it for a while: > > Phillip Tao wrote: > > > I think DKIM can actually be split into two parts: the mechanical part > > of how to canonicalize and sign a message, and how to transmit the > > key/establish trust. > > > > So, I propose that unobtrusive signatures actually be built on the > > first part of that. > > This is a reasonable engineering design, and was actually where i > started when we were sketching out unobtrusive signatures initially. I > like the idea of being able to reuse the same technical tooling for > message canonicalization and header inclusion. > > After discussion with Kai, Andrew, and others (a summary of which was > already linked to in this thread), i came away convinced that neither > DKIM nor unobtrusive signatures would have much to gain (and some amount > to lose) from aligning those parts of the standards, even though i > understand the engineering rationale for sharing the work. > > For one example: if the policies about which headers to sign differ > between DKIM(2) and unobtrusive signatures, then it might actually > present a hazard to users of a shared library -- they might pick the > wrong policy at signing time. But unobtrusive signatures has a very > simple policy: the MUA signs *every* header field that the MUA knows > about. Will DKIM2 have the same policy?
Current thinking is that DKIM2 will sign EVERY HEADER except a specified set of trace headers, meaning that even adding another previously unknown header without declaring that you did so in a signed delta header would break the signature. > On Tue 2025-08-19 11:45:41 +0200, Kai Engert wrote: > > On 8/18/25 20:58, Phillip Tao wrote: > >> Similarly, implementors do not have to worry about cases like the > >> inner headers not matching outer headers. > > > > Andrew, DKG and myself were discussing which consistency checks between > > inner and outer headers should be done, but we haven't yet updated the > > draft. > > There are now two different concrete proposals that try to address the > risks of potential inconsistency: > > https://gitlab.com/andrewgdotcom/unobtrusive-signatures/-/merge_requests/17 > https://gitlab.com/andrewgdotcom/unobtrusive-signatures/-/merge_requests/19 > > I'd welcome feedback from anyone in mailmaint who wants to take a look > at those. > > Kai Engert wrote: > > > By using the currently proposed mechanism, which adds a MIME layer > > around the inner message, we get a header section inside the > > body. This will also give us a good place for adding extra headers > > that are relevant for end-to-end security (for example key material) > > and that don't need to present at the outer header section. By placing > > them into the inner section in the body, only, we avoid increasing the > > outer header section further. Because there is a maximum size for the > > outer header block, as I understand it, and because future key > > material for post quantum cryptography might be big, being able to > > move those extra headers into the body seems like a useful benefit. > > This is the crucial bit that convinced me to move forward with the MIME > structure approach outlined in unobtrusive signatures. If there are > headers that are only meaningful to the recipient of an e2e context, > there's no reason to put them in the outer header section, which is > where the MTAs have traditionally done their work. > > Finally, there is an issue of development cadence. If unobtrusive > signatures are supposed to have the advantage of relying on DKIM2 > tooling, but that tooling isn't available, or is still in flux, it could > delay the process of deploying unobtrusive signatures. Or, if > unobtrusive signatures comes up with a requirement for > canonicalization/signing/signature transmission that wasn't a goal for > DKIM2, asking to change the DKIM2 outlines so that they align could > delay DKIM2 itself. Yes, this is the major issue - combing the work will slow one/both. On the flip side, being able to use the same signature and delta tracking all the way from first sender to final receiver (so you can verify everything at every level) would be really nice. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
