Re: [dmarc-ietf] ARC questions
In article you write: >questions the wg deems needed since then. Leaving ARC in an experimental >state ad infinitum doesn't seem optimal. Basically: 1) was it needed at >all 2) did it help. 3) if it helped, how much did it help. I agree that at some point we need to declare the experiment over and see if it's worked, but it's way too early for that. At this point the only widely used list software that can apply ARC seals is Sympa. (Mailman 3 may, but most mailman users including the IETF are still using mailman 2.) > (1) in >particular is what interests me because adding two new signatures seems >*really* heavy handed. That would go a long way toward answering the >questions of whether it's should go standards track. I don't get why a few extra signatures are a problem. Nearly all of my mail goes out with two added DKIM signatures, one that matches the >From domain or the list domain if it's a list, and one for my system. It's just not a big deal. >Our motivation at the time was one in particular: spear phishing. From >an enterprise situation spear phishing is scary af, and not one that >providers have much care about. That's what John gets wrong when he says >that 90% pass rate is useless: for enterprise not wanting to get spear >phished, a 10% false positive rate ... Sorry, I meant 90% the other way, catching 90% of the bad stuff and letting the other 10% through is not good enough. I agree that for spear phishing the tolerance for false positives is likely to be fairly high. R's, JOhn ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC questions
On 11/26/20 1:56 AM, Murray S. Kucherawy wrote: ARC was developed over months, even before this WG started, and I remember all of these conversations happening involving the questions you're now asking. We landed at what became ARC. I suppose an appendix might've been nice enumerating everything that was considered and discarded, but that record doesn't really exist. Yeah, like I said that's sort of a common failing of IETF documents in general. I mean, I understand at a very low level what's going on here, but given the document I am completely clueless of the *why* of things are going on. It's very frustrating, doubly so when it's a self-labeled experiment. Where do you suggest we go from here? I would think that an informational RFC might come in really handy both to answer the questions in ARC itself, and any other subsequent questions the wg deems needed since then. Leaving ARC in an experimental state ad infinitum doesn't seem optimal. Basically: 1) was it needed at all 2) did it help. 3) if it helped, how much did it help. (1) in particular is what interests me because adding two new signatures seems *really* heavy handed. That would go a long way toward answering the questions of whether it's should go standards track. I haven't put hand to coding keyboard on this problem yet, but I'm trying to imagine how it would be easy to determine (a) that Subject had been modified (for example), (b) what the specific modification was, and (c) which hop did it. You could say a message failing to validate an author signature with "[...]" at the front of Subject was likely tagged by an MLM, or that everything after "--" should be ignored, or that those probably happened at non-submission hop #1, but those are heuristics, and I think we're hoping for something more deterministic. The 80/20 rule isn't sufficient. But it's late and maybe I'm missing something. What did you have in mind? Our motivation at the time was one in particular: spear phishing. From an enterprise situation spear phishing is scary af, and not one that providers have much care about. That's what John gets wrong when he says that 90% pass rate is useless: for enterprise not wanting to get spear phished, a 10% false positive rate issuing warnings might be acceptable, and since we were grappling the intractable mailing list reputation (at least from our standpoint), maybe a better option. But it was a combination of the l= value in the original signature to clip off what the mailing list added, and some heuristics on the subject line to remove added text. I had quite a few of them, and they were certainly pretty dodgy, but by and large they worked. The object was not to get to 100%, but just an acceptable false positive rate. At the time I mentioned that maybe it would be good to create a DKIM-friendly mailing list BCP, but that was scoffed at by the usual suspects because there was supposedly a massive long tail of transformations that can happen that nobody would quantify as to how common or important they were. Hence my desire of this being driven at least in part by numbers. Sure, but the easier answer: to use my mailing list, you must have either DKIM, SPF or both. Sounds like a good way t o not be essentially an open relay. Don't mailing lists have those sorts of policies these days? I would say that ones that don't probably shouldn't have good reputations since they are, in effect... open relays. That requires MLMs to change their behavior, which I believe is something all of these protocols are hoping to avoid (or, at least, MLMs should decide that on their own, not because the IETF forced them to by wielding DMARC and ARC at them). I don't see making mailing lists coerced into better behavior as a non-starter. Everybody has had to change over the years to get mail delivered, and mailing lists, etc, shouldn't be viewed as sacred cows. If they want to forward their mail, they need to play by the evolving rules so as to make for a less spammy and phishy world. Back when DKIM was the new kid on the block, that might have been a valid argument. Today, not so much. PS: it's been, what, 15 years since our interop, partner? :) 2007. Still got the t-shirt. But we interoped the combined DK and IIM spec a couple of years earlier, right? What a great day that was... we dunn'em proud, Murray :) Mike ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC questions
On 26/11/2020 10:56, Murray S. Kucherawy wrote: On Wed, Nov 25, 2020 at 4:52 PM Michael Thomas wrote: Yeah, quantifying the problems kinda seems like the first order of business if you ask me. Quantifications will differ depending on what you count. Total number of messages versus total number of mail operators who find ARC useful. Small operators had better not forward spam, whether ARC sealed or not. Software. Only software can pry apart that ball of header spaghetti. But I think with the simple a mailing list it is pretty easy to determine, which now that I think about it I actually did back in the day when I was experimenting with recovering mailing list modifications. It didn't occur to me that that was supposed to be hard. I haven't put hand to coding keyboard on this problem yet, but I'm trying to imagine how it would be easy to determine (a) that Subject had been modified (for example), (b) what the specific modification was, and (c) which hop did it. You could say a message failing to validate an author signature with "[...]" at the front of Subject was likely tagged by an MLM, or that everything after "--" should be ignored, or that those probably happened at non-submission hop #1, but those are heuristics, and I think we're hoping for something more deterministic. The 80/20 rule isn't sufficient. Again, you cannot get 100% lists. For example, anonymizing lists will never let you recover an author domain's signature. MLM has to comply. On a compliant list like this one, you cannot get 100% users. For example, those who sign a Content-Type: multipart/alternative without giving the original value, or a quoted-printable body that the MLM will encode differently will never verify. Author domains have to comply. On a compliant list, you can verify 99.99% compliant author domains' signatures. (~0.01% due to cosmic rays and similar accidents.) Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC questions
On Wed, Nov 25, 2020 at 4:52 PM Michael Thomas wrote: > But what about DKIM? And why do they need to be processed differently? > When I first saw this, I looked at the ARC-Signature which looks identical > to a DKIM signature (i didn't notice the i= at the time), and am like what > is this? The i= counter could be trivially be grafted onto DKIM if it were > needed, which I'm still sort of dubious (though it is a nice to have > feature, I admit). That way you only need a single DKIM signature with the > OAR's signed. As far as I can tell, that would fall back gracefully for > non-implementing DKIM verifiers. Do you disagree? > ARC was developed over months, even before this WG started, and I remember all of these conversations happening involving the questions you're now asking. We landed at what became ARC. I suppose an appendix might've been nice enumerating everything that was considered and discarded, but that record doesn't really exist. What that means is that I couldn't tell you now why we rejected a pure DKIM/OAR solution to this specific problem, but I know it was considered. Maybe others who helped with RFC 8617 remember. > > Yeah, quantifying the problems kinda seems like the first order of > business if you ask me. I mean, how many of these scenarios are in reality > goofy self-inflicted wounds? I can't say but there seems to be a lot more > "this can happen" than "this is how often this happens" from what I've see > thus far on this thread. > Where do you suggest we go from here? > > When you say "easy to see", do you mean for software or for humans? > > Software. Only software can pry apart that ball of header spaghetti. But I > think with the simple a mailing list it is pretty easy to determine, which > now that I think about it I actually did back in the day when I was > experimenting with recovering mailing list modifications. It didn't occur > to me that that was supposed to be hard. > I haven't put hand to coding keyboard on this problem yet, but I'm trying to imagine how it would be easy to determine (a) that Subject had been modified (for example), (b) what the specific modification was, and (c) which hop did it. You could say a message failing to validate an author signature with "[...]" at the front of Subject was likely tagged by an MLM, or that everything after "--" should be ignored, or that those probably happened at non-submission hop #1, but those are heuristics, and I think we're hoping for something more deterministic. The 80/20 rule isn't sufficient. But it's late and maybe I'm missing something. What did you have in mind? > Sure, but the easier answer: to use my mailing list, you must have either > DKIM, SPF or both. Sounds like a good way to not be essentially an open > relay. Don't mailing lists have those sorts of policies these days? I would > say that ones that don't probably shouldn't have good reputations since > they are, in effect... open relays. > That requires MLMs to change their behavior, which I believe is something all of these protocols are hoping to avoid (or, at least, MLMs should decide that on their own, not because the IETF forced them to by wielding DMARC and ARC at them). > Mike > > PS: it's been, what, 15 years since our interop, partner? :) > 2007. Still got the t-shirt. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions
On 25/11/2020 20:16, Michael Thomas wrote: On 11/25/20 11:11 AM, Alessandro Vesely wrote: On 25/11/2020 19:24, Jesse Thompson wrote: On 11/25/20 11:30 AM, Alessandro Vesely wrote: Without resorting to ARC, it is still possible to validate author domain's signatures directly if the MLM just adds a subject tag and a footer, like, for example, this list does. While ARC solves "deep" forwarding problems, which may arise in the context of email address portability, MLM transformation reversion solves the simpler mailing list problem, including reverting munged From:'s. I agree that ARC isn't really needed to do this (trust the last hop from the MLM and determine the original authenticity from the MLM's perspective) I didn't mean to trust the MLM. I meant remove the subject tag and the footer, then the original DKIM signature verifies. See: https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ When I was at Cisco, with l= and some subject line heuristics I could get probably like 90+% verification rate across the entire company, a company that uses external mailing lists a lot. Definitely not 100% though. DKIM itself is not 100%. You always have lines beginning with "From " or occasional autoconversions. l= doesn't cover multipart/alternative nor Content-Transfer-Encoding: base64. In addition, the DKIM spec discourages its usage and suggests that "Assessors might wish to ignore signatures that use the tag." Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
