Condensing a few separate replies. - Phillip
> On Aug 10, 2025, at 5:34 PM, John Levine <[email protected]> wrote: > > It appears that Andrew Gallagher <[email protected]> said: >> On 10 Aug 2025, at 18:50, John Levine <[email protected]> wrote: >>> >>> The current version of unobtrusive signatures uses PGP keys. If you want to >>> look >>> them up in the DNS, RFC 7929 tries to do that >> >> The suggestion was that the DNS lookup portion of DKIM v2 would *not* be >> shared with unobtrusive signatures, only the canonicalisation >> rules. > > I still don't understand what probblem this is supposed to solve. > > The DKIM canonicalization stuff is mostly relevant to mail headers. While > there > are strict and relaxed canonicalization models for the body, in practice > intermediate mail systems do not mess with the body and the two work the same. > > The current draft is a way of wrapping PGP signatures of a single MIME > body part containing copy of the message. Even fewer mail systems mess > with the contents of a single MIME body part, so there's nothing for > DKIM to canonicalize. Note that DKIM's header canonicalization is about > the real message headers, not the ones inside the MIME part. > > R's, > John > > -- > mailmaint mailing list -- [email protected] > To unsubscribe send an email to [email protected] The problem this is supposed to solve is: 1. Easier to implement - By sharing much of the underlying technology with a widely deployed (or rather, hopefully-soon-to-be-widely-deployed) authentication mechanism in DKIM2, it will be easier for both senders and receivers to adopt. Similarly, implementors do not have to worry about cases like the inner headers not matching outer headers. 2. Explicit compatibility with DKIM2 - Ideally, these signatures should not be broken by intermediate hops that conform to DKIM2's diff algebra. By explicitly sharing the same canonicalization and signing scheme as DKIM2, this would guarantee compatibility with the DKIM2 ecosystem. 3. No MIME structure alteration - These signatures are meant to be "unobtrusive". Part of that to, IMO, is that there's absolutely no impact on how the message is treated by the receiving MTA and MUA, regardless of the MUA's support for this scheme. From the draft/DKG's presentation in Madrid, it seems like this draft has been fairly well tested already, and seems compatible. However, it's obviously infeasible to test all existing MUAs, not to mention future versions of MUAs. There's significantly less risk of errant MUA behavior if the actual message body does not need to have a different MIME structure to support this signature scheme. This also simplifies interaction with things like Structured Email, in which certain MIME structures signal certain cases. > On Aug 11, 2025, at 12:35 AM, Kai Engert <[email protected]> wrote: > > On 8/8/25 00:39, Phillip Tao wrote: >> So, I propose that unobtrusive signatures actually be built on the first >> part of that. Meaning, rather than wrapping the headers in a multipart mixed >> and signing that, attaching a header field that very closely mirrors the >> DKIM2 header field, and following the exact same mechanism to sign the body >> and selected headers. > > See also the discussion we had during the past OpenPGP email summit: > https://www.openpgp.org/community/email-summit/2025/minutes/#cleartext-non-disturbing-signatures-in-headers-dkg Very interesting discussion. Thanks for the link. > > Here are two arguments that support inclusion of the end-to-end signature in > the body: > * the DKIM signature then also covers the e2e signature, > so it cannot be stripped without being noticed DKIM signatures can sign other headers. For DKIM2, I believe there's a proposal to just always sign all headers. DKIM1 can already sign this, and for DKIM2, we can explicitly design this so it fits into the ecosystem, so stripping this would be the same as stripping a DKIM2 signature at any hop. > * added mailing list footers break a DKIM-style signature, > however, if the footer is added as a wrapper around the body > (additional MIME layer added), then the inner signed part > can be clearly identified and could still be validated. Would that not violate the e2e mail guidance doc's concept that the cryptographic envelope should be at the top layer? And thus this would be an "errant layer"? Perhaps that's fine/intended, since the guidance doc essentially says that errant layers should be handled unobtrusively. > > Kai > > -- > mailmaint mailing list -- [email protected] > To unsubscribe send an email to [email protected] > On Aug 11, 2025, at 1:51 AM, Taavi Eomäe <[email protected]> wrote: > > Hi, > > On 08.08.2025 01:39, Phillip Tao wrote: >> Given that there's active work on DKIM 2, I imagine this could be done by: >> 1. The DKIM WG explicitly splitting the core draft in two, one to cover how >> to canonicalize and sign a message with a given key, and another to cover >> how keys are to be distributed via DNS. The unobtrusive signatures draft >> could then explicitly use the mechanism defined in the first. >> 2. The unobtrusive signatures draft being modeled very closely on DKIM (but >> with a different key distribution mechanism). > > If intention of this approach is to provide an alternative to current S/MIME > and PGP signing, then such a draft should be significantly more strict in > terms of which headers should be signed than the base standard. Such a > mechanism should not allow the mistakes of DKIM(1), where additional or > missing headers (that could be interpreted by MUAs) could be added without > breaking a signature. Yes, I think that's fine. I think the most valuable parts of DKIM2 that we'd want to share are: 1. Canonicalization algorithm(s) for headers and bodies 2. Diff algebra 3. General mechanism of how signatures are attached (i.e. as headers) However, I think it can have slightly different rules for what headers must be signed. > > This means that it still probably requires a separate draft to cover > canonicalization and signing. Correct. I propose splitting those parts out of the DKIM2 draft into a separate draft which this draft can reference. > > I would also like to see explicit support for multiple such signatures and > how to handle these cases, be it just different key distribution > mechanisms/ecosystems or just dual-signing in the context of post-quantum > algorithms. Agreed. > > > Best, > Taavi > > _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
