Hi! On 7/19/25 21:54, Wei Chuang wrote:
While I do like the idea of signing all the headers, and agree that this approach would encourage that, removing the "h=" would mean that forwarders would have to explicitly identify the header fields that they add. This is in addition to identifying mutations that they do. Perhaps a way to solve my concern is to identify how many header fields are part of the header hash initially, and for forwarders to identify how many they prepended or appended to the header fields.
IIRC the header changes algebra can represent previous headers. Possibly not fully efficiently in the "I just added another Foo field" case, but it can.
An optimization for this case could make sense (a bit like in the body changes algebra, possibly, like the previous version of a field could be created using a kind of "copy" instruction instead of inlined previous values).
Then, there are few standard headers that can be multiple. Some are trace or trace-like and we might not want/need to sign them - though I could see a point of committing to Resent-*.
We could either special-case the latter (i.e. only sign the latest step, and if we want to verify previous ones, we expect previous DKIM2 signatures to cover those instead). Or we could just go and specify "we commit to all copies of a signed header in our version of the mail and cover additions/removals using the change algebra.
I generally prefer fewer/no special cases. That is, I'd prefer if a DKIM2 library doesn't "know" all too much about Internet Message Syntax except for the header being a sequence of fields with folding, followed by a body. The exception would be DKIM2-* headers and the "preloaded" h= list.
Hannah.
-Wei
On Mon, Jul 14, 2025 at 9:24 AM Hannah Stern <[email protected] <mailto:[email protected]>> wrote:Hi! I know I'm late but: On 4/7/25 06:35, Wei Chuang wrote: > In an offline conversation with Bron and Tobias, they described a likely > improvement to the header signing method described 26 March 2025. The > following is my description of that proposal. The change is that all > headers fields of a given name are signed, instead of worrying about the > DKIM1 style of order sensitive "h=" header field name list. This also > solves the problem of worrying singletons vs trace headers and how to > protect against newly added header fields i.e. "oversigning". > > > As noted on 26 March, the recommended header field list is: > > * From > > * Reply-To > > * Subject > > * Date > > * To, Cc > > * Resent-Date, Resent-From, Resent-To, Resent-Cc > > * In-Reply-To, References > > * List-Id, List-Help, List-Unsubscribe, List-Subscribe, List- Post, List- > Owner, List-Archive > > > Hashing procedures > > 1) Find in the message which of the recommended header fields are > present. Read the header fields in the order found in the recommended > header field list, I'd suggest sorting headers by case-insensitive lexical sort of header field keys, and within the same key, by original order in the header. This way, no hard-coding of a magical un-intuitive order is needed, the pre-configured always-signed headers can be a possibly unordered set at the developer's convenience. > and canonicalize using the Relaxed algorithm found in > RFC6376 section 3.4.2 <https://datatracker.ietf.org/doc/html/ <https:// datatracker.ietf.org/doc/html/> > rfc6376#section-3.4.2>. Then successively hash them. While not > expected, if multiple header fields of a given name are found, read them > from the header field in a bottom to top order as described in RFC6376 > section 5.4.2 <https://datatracker.ietf.org/doc/html/ <https:// datatracker.ietf.org/doc/html/> > rfc6376#section-5.4.2>and hash in that order. I'd suggest removing the reversal (bottom to top). The reversal made some sense in the old DKIM, where only a subset of fields with the same key might be hashed/committed to, as to allow adding more fields with the same key _at the top_. As DKIM2 is supposed to commit to all copies (and thus, implicitly the absence of excess copies) for a field key that is signed, this reversal is obsolete. Oversigning is moot, too, as signing 2 copies of header field key Foo already commits to exactly those 2 copies. > 2) Take the list of extra header field names given in the colon > separated "h=" header field name list, and read the header field in the > order found. Canonicalize using the Relaxed algorithm found in RFC6376 > section 3.4.2 <https://datatracker.ietf.org/doc/html/ <https:// datatracker.ietf.org/doc/html/> > rfc6376#section-3.4.2>then successively hash them. If multiple header > fields of a given name are found in "h=", read them in a bottom to top > order as described in RFC6376 section 5.4.2 <https:// > datatracker.ietf.org/doc/html/rfc6376#section-5.4.2 <http:// datatracker.ietf.org/doc/html/rfc6376#section-5.4.2>>. If not found, > treat the value as empty. Unlike section 5.4.2, for each name in "h=", > if multiple header fields with the same name are present, all instances > will be hashed. See above. In terms of order, I'd suggest sorting them lexicographically, together with the fixed mandatory set of header field keys. > [...] > There is also an extra header field name "h=" list tag validation > procedure. The names in the "h=" list at some later instance number > "i=" must be a superset of earlier ones. A simple but restrictive check > would require that any earlier instance number "h=" names must be a > prefix of a given "h=" name list. With the approach that the header field keys are unordered set (sorted in hashing/canonization), "superset" would be it instead of over-restricting it to prefix. Hashing would thus be "determine list of header field keys to be signed, based on the fixed set plus the additional set from h=; for each of this list, get all fields with the stated key, canonicalize 'relaxed', add to hash". > [...] Regards, Hannah.-- Hannah Stern Mail System Developmentwww.mail-and-media.com <http://www.mail-and-media.com> 1&1 Mail & Media Development & Technology GmbH [email protected] <mailto:[email protected]> Brauerstraße 48 76135 Karlsruhe Germany +49 721 91374-4519 <tel:+49%20721%20913744519> Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452 Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Dana Kraft, Thomas Ludwig Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail. _______________________________________________ Ietf-dkim mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
-- Hannah Stern Mail System Development www.mail-and-media.com 1&1 Mail & Media Development & Technology GmbH [email protected] Brauerstraße 48 76135 Karlsruhe Germany +49 721 91374-4519 Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452 Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Dana Kraft, Thomas Ludwig Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail. _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
