On Wed, Jul 16, 2025, at 19:45, Bron Gondwana wrote: > On Wed, Jul 16, 2025, at 17:05, Barry Leiba wrote: >> What's wrong with something like this: >> The verifier MUST support at least one of the signature algorithms. >> The verifier SHOULD check all the algorithms it supports. >> The signature MUST be valid for all signatures that are checked. >> ...and we add an explanation for the SHOULD. > > Yeah, I think I agree with you. When adding a new algorithm support I would > be likely to put it in a "check but don't use" state, where I'd log the > result to see if it was well implemented at either my end or the sending end, > and once it looked like it was generally solid I'd turn it on for real.
Speaking with Barry in person at the hackathon today, I am persuaded that what we actually want to have in the spec is this: The verifier MUST support at least one of the signature algorithms. The verifier SHOULD check all the algorithms that is supports The signature MUST be valid for at least one of the signature algorithms which are checked. The signature SHOULD be valid for all signatures algorithms which are checked (however, the verifier MAY decide to just log signature failures for new signature algorithms during a transition phase, while interoperability is not yet reliable). I am persuaded of this for two reasons: 1) an attacker trying to replace/fake a message could always just create a message with only the "broken" algorithm. It's always possible to replace the i=MAX DKIM2 header with a new DKIM2 header. 2) all the later hops can validate all previous signatures, so if they aren't happy about the content of a message they can tell if it was insufficiently checked by a previous hop (which they need to do anyway, because any hop can lie about the validation is has done of previous hops. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
