Hi!
On 8/27/26 01:30, Richard Clayton wrote:
In message <[email protected]>, Hannah Stern
<[email protected]> writes
>> sha512 is now required as a hash function alongside sha256. This is
>> mainly to allow implementors to test their code for multiple hash
>> functions; we might want to take it out before finalising the
>> document but for the moment it is a MUST for Verifiers
> I observe that for the "top-level" hash/signature, we still only have
> rsa-sha256 and ed25519-sha256. Cryptographically, I'm not sure how much
> sense it makes to have sha512 in Message-Instance, but then hashing
them
> (textually via the Message-Instance fields) with sha256 at signing time.
sha256 is just fine from a cryptographic point of view (he says as a
someone who tries to keep up with consensus rather than a real expert)
the point of adding sha512 was to ensure that people actually read the
string rather than just assuming it said sha256
That makes some sense. I saw that the addition is possibly temporary,
for correctness/interop testing.
note that different things are hashed for M-I and for D-S (ie its not
that there is part-calculation hanging around that you could use to
speed things up)
Yeah that's a relatively clear basic thing. M-I hashes bodies and
headers separately. For the D-S signature, you hash only a collection of
M-I + D-S headers (for the last one, existing signatures replaced by
empty string).
I'm not yet implementing the production signer, I'm at the verifier. I
actually verify D-S first (i.e. sha256 of the selections of M-I/D-S,
then verify each signature entry, reusing the hash if one D-S has more
than one signature). If that's ok, I go through M-I/recipes: First I
check which hashes are used in any M-I (as to not calculate sha512 if no
M-I uses it, for example). Then I go through and calculate hashes
(reusing them if no recipe changes the content) and then I validate
them. It's not 100% efficient as I calculate all sha512 hashes even if
only one M-I uses it, but better than nothing and hashing is not too
expensive.
>> there is now text to forbid repetition of algorithm or selectors
>> (there's no interop issues here, but it means you can reject
>> messages that are just trying to push up your electricity bill)
> I read some inconsistency there:
> - For M-I the language is clear, only at most one hash of a given type
yes
> - For D2-S, the language is less clear. I interpreted the previous
draft
> to forbid duplicate selectors already, but not duplicate algorithms.
Now
> the language says that duplicate algorithms are actually allowed,
but at
> most 2 signatures per algorithms.
yes you understand the language correctly ... it occurred to me as I was
writing this bit that people might want to sign with two keys because
they were transitioning from one to another. However, if you removed one
of the keys from the DNS then a Verifier has one signature that worked
and one signature that gave an error.
Yeah, and our current rules would reject that. A key should be in DNS at
least for 14 days after it has been last used for signing.
So today I think this was probably a mistake and unless anyone loves it
(and can tell us how to combine the two results) then I will insist on
just one signature per algorithm (which mean unique selectors because
keys say which algorithm they are for)
I think there's _one_ legitimate use case I can think of:
The draft says that implementations MUST support RSA keys only up to
2048 bits, but MAY support more.
So a sender could add 2 RSA signatures: One with 2048 bits that's
supported by all verifiers. And one extra with a stronger key.
Verifiers that support only up to 2048 bits check only that one and skip
the other one. The draft says a verifier MUST verify all signatures _it
supports_. So that would work.
Verifiers that support longer RSA keys would check both and thus have
stronger security.
Forcing the sender to use only one RSA signature gives it the choice:
Use 2048 bits (weaker security) or use a stronger key only (less
interoperable).
However, for the verifiers that support the stronger key, spec language
seems still ambiguous:
The verifier MUST return fail only if _all_ supported signatures fail
verification, while if some fail and some pass, it lowercase-should
return a PERMFAIL (and then just below, the example error string is
specified as FAIL instead of PERMFAIL, which is inconsistent too)?
> - But later in the error messages, there's the error string
> "DKIM2-Signature i=<x> has too many signatures" suggesting a limit
(from
> the standard, not operationally imposed) on _total_ number of
signatures
> per DKIM2-Signature field?
the idea was you would issue this if the two was exceeded
I'd suggest:
- Weak preference: Support up to 2 signatures per algorithm (as per the
current draft); if that is done, adjust the example error string to be
clear it's too many _per algorithm_ and not an overall limit that's been
exceeded. Alternative: Only one per algorithm (would preclude that one
use case suggested above, though).
- Specify that if _any_ supported signature fails verification, a
verifier MUST return an overall failure (possibly with details). I think
there's no legitimate case for accepting D2-S fields with one supported
signature being correct and the other incorrect.
- Fix the PERMFAIL vs. FAIL inconsistency
- Possibly add prose to strongly recommend that when planning to remove
a key (after rotation), it should be kept in DNS for at least 14 more
days after it's been last used for signing (14 days from the
"Implementations MAY ignore signatures that are more than 14 days old"
language).
- And by the way, possibly not just allow verifiers to _ignore_ too old
signatures/signatures from the future, but make it a failure condition
(SHOULD FAIL or PERMFAIL (I'm not sure which fits better)), perhaps with
prose to allow implementations to add some tolerance, but requiring the
age limit to be at least 14 days.
Kind regards,
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]
