This could apply to other things like over some rate limit threshold or the reputation based approach I suggested as well. The key thing that's relevant to the problem statement is that the problem is how the reputation impact of the signature is applied, not signature continues to validate after replay.
Scott K On February 16, 2023 10:13:03 PM UTC, Barry Leiba <barryle...@computer.org> wrote: >I like this approach: if the issue is that an "expired" signature is >treated as unsigned, I think we have an unacceptable level of false >positives. But if the fact that a signature is valid but expired is >simply another factor in the decision, I think we might be OK, keeping >in mind that "x=" is purely advice to the validator. To *really* >expire a signature, one has to stop publishing the key associated with >the selector. > >Barry > >On Thu, Feb 16, 2023 at 4:38 PM Scott Kitterman <ietf-d...@kitterman.com> >wrote: >> >> >> >> On February 16, 2023 9:21:51 PM UTC, Michael Thomas <m...@mtcc.com> wrote: >> > >> >On 2/16/23 12:56 PM, Barry Leiba wrote: >> >>>> Okay. What's the value for X - T that prevents this problem, but >> >>>> doesn't cause DKIM signatures of "normal" mail to fail? >> >>> There's not one "right" value; we're talking about distributions >> >>> of timings for normal mail vs. replay, and yes, there's some >> >>> overlap there. In practice I've seen many signers choose >> >>> expirations in the range of 1hr to a few days. 1hr can be very >> >>> good at limiting the opportunity for high volume replay, but I >> >>> estimate "normal" signature breakage at that level is on the >> >>> order of 0.1%. 24hr is probably effectively zero breakage, but >> >>> with greater opportunity for replay. >> >> I think you're way off on these numbers, especially for the 1-hour >> >> case. While normal circumstances get mail delivery in less than an >> >> hour, I have seen *many* cases of legitimate mail delayed by hours -- >> >> sometimes quite a few hours. I would consider anything less than two >> >> days to be unacceptable, and with that sort of gap you don't do much >> >> to prevent a spam blast. >> > >> >I dunno, I would think it has to do with how much of a boost reputation is >> >actually giving deliverability. For typical marketing email that's not too >> >spammy maybe it doesn't make much difference? Adding signatures and a SPF >> >record is pretty easy to do these days, so it's sort of a no-brainer to >> >just do it. But if some small percentage with slow delivery fall through >> >the cracks, how adverse is that to delivery, assuming they don't have a >> >p=reject policy? That seems like it should be a pretty measurable thing for >> >an ESP. >> > >> >Sounds like something that Evan might know. Actually it might well be worth >> >adding that kind of estimate to the problem statement to judge how much of >> >a problem it is. What we have now is very hand waving and makes it >> >impossible to judge about how heroic we need to be. >> >> I think this highlights a key consideration that's easy to forget. >> Ultimately the issue is not that a 'bad' message was delivered, but that a >> 'bad' message got the benefit of whatever positive reputation was provided >> by the signature. If one decides under X circumstances we will ignore a >> DKIM signature for Y purposes, then the negative impact of that is far less >> than that associated with rejecting the message, so we can probably tolerate >> more false positives. >> >> Scott K >> >> _______________________________________________ >> Ietf-dkim mailing list >> Ietf-dkim@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-dkim > >_______________________________________________ >Ietf-dkim mailing list >Ietf-dkim@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-dkim _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
