On Fri, Jan 19, 2024 at 7:01 AM Dave Crocker <d...@dcrocker.net> wrote:
> On 1/19/2024 6:51 AM, Al Iverson wrote: > > I'm > sort of boggling at the attempt to keep potential header changes and > DKIM oversigning out of the exploit definition and potential solution > consideration. I just don't think it makes sense to exclude this. > > > It makes sense because oversigning is sufficient to cover the cases of > re-posting that 'merely' add header fields, whereas the scenario of sending > to a collaborating receiver and re-posting a message that has no > differences except the envelope rcpt-to value, does not have a know > solution. > > Insisting on using the same term for these two different cases has an > academic purity to it, but has already been demonstrated to be destructive > in practical terms, because it creates confused discussion. > No, that's exactly backwards. The oversigning case is a subset of the general DKIM replay case, because mitigation techniques for general DKIM replay - they do exist, though they are imperfect - also apply to cases where header addition has taken place. Oversigning is a defense against the subset of DKIM replay where headers have been added, but not the general case.
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
