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
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]
