Sorry to be late to this thread. 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.
-Wei On Mon, Jul 14, 2025 at 9:24 AM Hannah Stern <hannah.stern= [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/ > > 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/ > > 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/ > > 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>. 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 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 <+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] > To unsubscribe send an email to [email protected] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
