All, Revision 08 of the deployment profile has been submitted. https://datatracker.ietf.org/doc/draft-moccia-dkim2-deployment-profile/08/
The main change is that the profile is now self-contained in its own header fields: it no longer places tags inside the DKIM2-Signature header field of the base specification. A message can therefore carry a chain under draft-ietf-dkim-dkim2-spec and a chain under this profile at the same time, with no field and no tag in common. The revision also tracks revision 08 of the base specification. Changes from revision 07: - The profile is now self-contained in its own header fields. Its tags no longer appear inside the DKIM2-Signature header field of the base specification: it defines DKIM2-Chain-Sig with its own tag set and formal syntax. The other fields are named to match: DKIM2-Chain-mf, DKIM2-Chain-rt, DKIM2-Chain-Mod and DKIM2-Chain-Results. A message can carry a chain under the base specification and a chain under this profile at once, with no field and no tag in common, so the two can be run in parallel and a verifier of either reads only its own fields. - New continuity check between consecutive hops (Section 3.3.8). The domain of the envelope sender at one hop must match a recipient domain at the hop below it, so extension of a chain is restricted to parties that actually received the message. A failure of the check is cryptographic proof of dishonesty rather than a failure of undetermined cause. - Envelope sender rewriting is now required of a node that forwards and signs (Section 3.1.4). It follows from the match between the signing domain and the envelope sender and from the continuity check above. - The treatment of a signature that attests a transaction it received rather than one it presents is now specified (Section 3.1.6). It covers intra-ADMD signing, the externally facing node that is not the signer and the nd= case of the base specification, with the match that applies in place of the match between the signing domain and the envelope sender. - The BCC treatment now states which transactions are representable in DKIM2 at all (Section 3.1.5): either every recipient is visible in To or Cc or the transaction carries exactly one recipient that appears in neither. A signer presented with any other combination does not emit the envelope binding fields, does not sign and removes the fields of earlier hops, so the message leaves with no chain rather than with one that describes a different transaction. The consequences of that downgraded transaction are stated. - The identity in the From header field is checked against every value the field has held, by a descending walk over the modification declarations (Section 3.1.2). A plural From, the group syntax of RFC 6854 and a domain literal each have a defined outcome. - New section on the content-modifying components that operators install deliberately and on the topology they require (Section 3.7.7). An antivirus engine, a DLP system, an encryption gateway or a content filter is not an autonomous node on the path: it sits inside the administrative domain of the sending or the receiving operator. That domain is required to place a DKIM2 signer downstream of the component, so that the modified state is attributed to the domain by signature while the component itself needs no knowledge of the protocol. The signer does not describe what was changed: it states that the message left the domain in the state presented and that the domain accounts for it. - The cryptographic algorithms section is largely new (Section 3.6). It states the mandatory set and why this profile does not adopt the larger set that revision 08 requires of verifiers. It records the cost a post-quantum key carries at verification time and the ecosystem's record on algorithm transition, measured at two mailboxes. A hop that signs with several algorithms is judged on every signature the verifier can check, so the failure of one is the failure of the hop. The ordering of signatures within a hop gives the most widely implemented algorithm the role of a witness to the presence of the others. The profile does not act on the grouping declaration of revision 08 and gives its reasons. - New optional DNS declaration of signing algorithms (Section 3.6.1). A TXT record at _dkim2.<domain> lists the algorithms a domain signs with, evaluated per hop against the signing domain of that hop, so that the removal of a signature in a stronger algorithm becomes detectable rather than indistinguishable from its absence. - New result value neutral in DKIM2-Chain-Results (Section 3.5.1) for a hop accepted on the signatures the verifier was able to evaluate, with the algorithm that was not evaluated named in the comment. This profile does not treat an unimplemented algorithm as a permanent error and follows RFC 6376 Section 3.3.4 instead. - The graduated enforcement model is developed (Section 3.5.2). It separates a structural failure, a transient failure, a failure that is cryptographic proof that a participating node misdeclared its modifications and a failure whose cause cannot be determined from the message. The disposition of each is stated for the phase in which rejection applies. - Signature numbering within a hop tightened (Section 3.3.3), eight-bit content and transport conversion addressed (Section 3.3.9) and internationalization stated. - The three enforcement phases are separated and named (Sections 5.6.1 and 5.6.2). Entering the terminal phase is stated as a decision to refuse the mail that still traverses non-participating nodes rather than a finding that none remain. - Aligned with revision 08 of the base specification: the mandatory verifier algorithm set, pure ML-DSA-44 in place of the composite algorithm, the Fully Verified terminology and its renumbered sections. - Deployment evidence added: the bound every body recipe generator has adopted and what happens past it, the handling of a footer appended to a single-part post, the shared state that recipe generation requires while signing and verification remain stateless and the distribution of signing algorithms observed at two mailboxes. - Analysis extended: the depth of verification that the base specification leaves to the verifier and the onward transmission prohibition that rests on it (Section 4.3), recipe literals that are not valid UTF-8 (Section 4.4.2), the implementation experience of specification ambiguity (Section 4.7), the effect of parser divergence on the uniformity of delivery (Section 8.3.1), the comparison of the tag-value encoding with the JSON recipe encoding (Section 9.2) and the proposal that updates DMARC to recover the author domain from the signature at i=1 (Section 5.7). - The encoding and comparison of values are specified in sections of their own (Section 3.8): the principle the syntax follows, the encoding of a declared header field value, the encoding of envelope addresses, the naming of header fields and the comparison of domain names. - The milter implementation notes move from an appendix to a numbered section. - References updated, including DMARC RFC 9989. Regards, Vittorio Moccia _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
