Re: [Ietf-dkim] Misuse of antiforgery protocols
On Sun, 25 Dec 2022, you wrote: >> It's easy to sort wanted mail between forwards/mailing-lists and normal >> narrow-casted mail. Spam can masquerade as either; but if possible a >> spammer would want to look like narrow-casted mail as that is the only >> kind that could be expected to arrive from a stranger. To use this >> exploit, they must give that up. >> > If you're talking about replay, I don't understand "must". The replay > attack under discussion works fine if it's unicast. The spammer wants it to *look* unicast, not actually be unicast. That means the From: and To: align with MAIL FROM: and RCPT TO:, and that the single From: address passes all available forgery checks. The To: header is covered by DKIM, hence the spammer *has* to use a generic To: that can be correct for at most a single intended victim. While in theory he could do the trick once for each victim, that's silly as it means one pass through the singer-victim's smarthost *per* spam victim. He's giving up the advantage of blinding his signer-victim's Abuse Desk to the true "fan-out" of his e-mail, which is the only reason to consider this hack. Michael Deutschmann ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On 12/25/22 7:55 AM, Murray S. Kucherawy wrote: On Sun, Dec 25, 2022 at 6:31 AM Barry Leiba wrote: I agree with Mike and Scott on the point that it’s worth explicitly allowing the result to be a “can’t do it” publication. Implicit “couldn’t do it” is fine in most cases, but here we might say something like, “If the working group decides that none of the proposed approaches will work acceptably well and is unable to find an acceptable alternative, it may instead publish a report describing the problem and summarizing the reasons that proposed approaches are not acceptable.” Making that explicit will avoid arguments about whether such a document is within the charter scope. Done, and thanks for that text. One nit, Barry's text should be above the proposals not below. It makes it look like those are the only proposals on the table which I'm nearly certain is not your intent. One other thing though, should there be some bounds on what appears to be the possibility of writing a BCP like document? I mean, I can think of some things that could help mitigate this but they are pretty wonky and definitely untested. Do we actually have that operational experience to recommend anything? Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On Sun, Dec 25, 2022 at 6:31 AM Barry Leiba wrote: > I agree with Mike and Scott on the point that it’s worth explicitly > allowing the result to be a “can’t do it” publication. Implicit “couldn’t > do it” is fine in most cases, but here we might say something like, “If the > working group decides that none of the proposed approaches will work > acceptably well and is unable to find an acceptable alternative, it may > instead publish a report describing the problem and summarizing the reasons > that proposed approaches are not acceptable.” Making that explicit will > avoid arguments about whether such a document is within the charter scope. > Done, and thanks for that text. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
On Sat, Dec 24, 2022 at 9:12 PM Michael Deutschmann wrote: > On Mon, 12 Dec 2022, you wrote: > > > Blind-carbon-copy is already a sign of spam. > > > > Except when it's not, like this very mailing list. > > Only if you don't whitelist *all* forwarders you set up and mailing lists > you have joined first, overriding the Bcc filter on a match. > I've always expected that requiring users to register and deregister every mailing list they join or depart would be interpreted as tedious and a disincentive, resulting in complaints (and thus support costs or lost customers) when they forget or get it wrong. It seems like a tactic that won't succeed at scale. > It's easy to sort wanted mail between forwards/mailing-lists and normal > narrow-casted mail. Spam can masquerade as either; but if possible a > spammer would want to look like narrow-casted mail as that is the only > kind that could be expected to arrive from a stranger. To use this > exploit, they must give that up. > If you're talking about replay, I don't understand "must". The replay attack under discussion works fine if it's unicast. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
I agree with Mike and Scott on the point that it’s worth explicitly allowing the result to be a “can’t do it” publication. Implicit “couldn’t do it” is fine in most cases, but here we might say something like, “If the working group decides that none of the proposed approaches will work acceptably well and is unable to find an acceptable alternative, it may instead publish a report describing the problem and summarizing the reasons that proposed approaches are not acceptable.” Making that explicit will avoid arguments about whether such a document is within the charter scope. Barry On Sat, Dec 24, 2022 at 4:17 PM Michael Thomas wrote: > > On 12/24/22 1:08 PM, Scott Kitterman wrote: > > > > On December 24, 2022 8:22:45 PM UTC, Michael Thomas > wrote: > >> On 12/23/22 10:25 PM, Murray S. Kucherawy wrote: > >>> On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas wrote: > >>> > >>> Shouldn't the problem statement explore whether there is a > >>> plausible tractable solution before it moves on to protocol work? > >>> That is, if there isn't a tractable solution the wg should go into > >>> hibernation again. I'm pretty sure that I brought this quite a > >>> while ago. Of if not the problem statement, afterward just > >>> evaluating for a go-no go decision before starting any work. > >>> > >>> > >>> A working group is implicitly allowed to admit defeat if it decides it > can't solve the problem it thought it was supposed to solve. DBOUND comes > to mind; it deadlocked on whether the problem was tractable, or even well > enough understood, to advance a consensus protocol solution, and closed > without producing anything. > >>> > >>> I don't think the charter has to say that expressly. It's part of the > process. The charter stipulates an ordering, and I think that's sufficient. > >>> > >> I think it's worthwhile for the charter to have a step which is to > determine whether the problem is 1) tractable and 2) requires IETF to do > something. If either of those are false, the charter should say that it is > completed. There has been quite a bit of skepticism expressed (and not just > by me) about both of those points so it would be good to have a checkpoint > before doing something to do something. > > > > +1. I think it's a mistake to assume deciding not to make protocol > changes by the group is a failure. A reasoned decision that additional > protocol changes would not be helpful would be a success, if that's where > the facts lead us (I have opinions on this, but have reached no definitive > conclusions). > > and write an informational RFC explaining the outcome. heck, it would > probably be worthwhile to keep an ID going during that period to > document the various ideas/approaches. > > Mike > > ___ > 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
