On Thu, Jan 5, 2023 at 10:43 AM Dave Crocker <[email protected]> wrote:
> On 1/5/2023 9:20 AM, Alessandro Vesely wrote: > > I wouldn't call "replay-resistant DKIM enhancement(s)" the > > deliverable. I understand the WG name is DKIM, but two of the > > proposed drafts don't even mention it. We may call ARC a "kind of > > DKIM", but a solution based on it would be better called an ARC > > enhancement, no? > > > > How about "replay-resistant protocol"? > > Just to explore this a bit further: > > 1. The motivation for the current effort has been exploitation of > re-posting to exploit a DKIM reputation. > > 2. Are there any other kinds of replay scenarios that are an issue now? > I suspect there aren't. > While not exactly ARC replay, we've seen recently that spammers are exploring munging the ARC headers. One campaign had them swapping a complete ARC header set into another message. In another they added an incomplete set. Consequently we're worried about the spammers exploiting ARC vulnerabilities. -Wei > 3. Whatever mechanisms are developed to prevent or mitigate replay, > their current use will be to deal with a DKIM-related replay problem. > > It's likely to be useful for the working group name to relate to a > specific, real and current problem, even if a technical solution doesn't > explicitly deal with the technical details of that problem. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > mast:@[email protected] > > _______________________________________________ > Ietf-dkim mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-dkim >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
