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? 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. Happy to talk more with interested people! Regards, --dkg
signature.asc
Description: PGP signature
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
