Hi!
On 7/10/26 00:18, Richard Clayton wrote:
I was asked to supply a list of "open issues" that it would be useful to
discuss at the Vienna meeting
Removal of null recipes for headers
ie: you always have to document what you changed
this considerably simplifies DSN handling, and it seems fanciful
that systems in the middle of the network are altering headers at
all, let alone in ways they are do not wish recipients to be able
to undo
Will work for us.
Should we explicitly forbid Message-Instance headers that only differ by
ordinal value
I wouldn't think we need such a formal constraint, but probably it
wouldn't hurt much either.
The spec has some MUST NOT's here but all they do is heat up the
planet, they don't actually cause interworking issues
PQ Algorithm
The chairs are going to ask for advice and we have had a discussion
on how that question should be phrased. Stephen Farrell suggested
just insisting that all signatures MUST pass (but long ago the WG
disliked that so we have a SHOULD at present)
I personally don't yet feel a real urgency for a PQ transition.
If I remember correctly, a verifier has to (or at least SHOULD) check
all signatures whose algorithm it supports, and if any of those fail,
SHOULD treat it as failure?
1. If there is more than one signature provided then they MUST all be
checked if the Verifier is able to do so. If any signature fails then
an error SHOULD be reported. If all signatures that can be
checked fail
then PERMFAIL MUST be reported.
1. If some signatures fail and other pass then any error that is
reported should provide that information (e.g. PERMFAIL "rsa-sha256
signature passed, ed25519-sha256 signature failed").
My current hunch about PQC algorithms is that they're still not as well
analyzed as the current "conventional" algorithms like RSA or ED25519.
If we now specify an additional PQC-only algorithm, this may lead to
reduced security if
- a Signer decides to use only that
- or a Verifier decides to override the lowercase "should" in the second
clause I cited, i.e. doesn't fail the whole verification if a Signer
used a conventional and a PQC-only algorithm and the former fails. (And
any report of OK, but one of the algorithms failed is ignored later or
just logged.)
Hence, _if_/_when_ we start specifying PQC (which I think we shouldn't
delay the basic specification over going into PQC country right now,
i.e. we should defer IMO), I'd strongly prefer that we specify a
"algorithm" in the DKIM2-Signature sense that is a ed25519+some PQC
hybrid _in one_, so there'll be no partial success in Verifier
evaluation in the first place if the PQC part passes but the ed25519 one
doesn't, but just an overall failure.
That is, a "PQ/T hybrid digital signature" in the terminology of RFC
9794 section 3. My motivation is described more elegantly there in
section 2, paragraph starting "To mitigate risks...".
Case issues in JSON
should we insist that header field names in the recipe JSON always
be in lower (or indeed UPPER) case ?
As written elsewhere. Some preference to yes making this constraint,
significant preference to lowercase if we do that.
[...]
Hannah.
--
Hannah Stern
Software Developer
Mail Transfer Development
1&1 Mail & Media Development & Technology GmbH | | |
Phone: +49 721 91374-4519
E-Mail: [email protected] | Web: www.mail-and-media.com www.gmx.net
www.web.de www.mail.com www.united-internet-media.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452
Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig,
Dr. Verena Patzelt
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]
