On Sat, Jul 19, 2025 at 9:43 AM Bron Gondwana <brong= [email protected]> wrote:
> > 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). > Very much agreed with the SHOULD here to support some notion of a transition period. And that's good point that we need to document how those new signature algorithm failures are reported during that transition period in Authentication-Results and DMARC reports at some near point (i.e. but probably not right away to let us focus on the core spec) > 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. > > +1 to Barry's sensible approach as well. My sense is that over the lifetime of "DKIM2" there will be more algorithm introductions than circumstances where there is an algorithm breakage, and the algorithm introductions need to be supported and encouraged for algorithm diversity. I suspect a MUST would discourage that. In those circumstances where there is believed to be an algorithm, this policy allows receivers to be able apply local policy to protect their users from spoofed signatures. If we further want to help receivers, consider adding an optional DNS policy record that describes the algorithms that the sender supports with certainty. It might not even be needed in the initial deployment, or not even describe algorithms that a sender signs with during the introductory transition period. However, in those circumstances where it is believed that algorithm breakage is imminent or ongoing, it can provide interested parties a way to discover the algorithms a sender supports with certainty such that a "MUST" support can safely be applied. -Wei
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
