On Mon, May 26, 2025, at 18:15, Dave Crocker wrote: > (Apologies for the delay in responding. Extended and draining travel and a > broken laptop got in the way.) > > > Bron, et al, > > Thanks for this note, which engaged with useful detail and provided useful > scenario data to consider. We need more scenarios. > > Also, on reflection, I've come round to the view that it will be useful to > explicitly support a chain of signatures along the transit handling path, > with annotations that indicate the order of the chain. The next draft of DKOR > supports that.
I'm glad to hear. I expect that as we flesh out the rest, you may come to something pretty close to what we initially proposed - I did spend quite a while thinking through the various details and discussing them in person with a few others who understand email pretty well. I would have discussed them in person with you as well if I'd had a chance, because I know you have a lot of experience and good logical skills. > Inline... > > > On 4/26/2025 1:51 PM, Bron Gondwana wrote: >> For succinctness I shall call your proposal DKOR and ours DKIM2 below, >> acknowledging that the name DKIM2 does not have consensus. >> >> On Sat, Apr 26, 2025, at 13:07, Dave Crocker wrote: >>> On 4/25/2025 8:13 PM, Bron Gondwana wrote: >>>> On Fri, Apr 25, 2025, at 12:31, Dave Crocker wrote: >>>> > > >>> HTTPS followed an incremental adoption path, not all that different from >>> what I've proposed, since there is utility for any pair of client and >>> server that adopted it. This is profoundly different from your proposal. >>> >> I disagree with your "profoundly different" assertion here. DKOR is a >> strict subset of the capabilities provided by DKIM2. DKOR provides benefits >> as soon as both a single sender and a single receiver implement it, for >> direct mail flows between those two systems. >> >> DKIM2 also provides immediate benefits as soon as two systems support it, >> for direct mail flows between those two systems. > As offered, DKIM2 requires massive infrastructure adoption, before being > useful. > > That is, it has so far only been offered as a single, integrated, > take-it-or-leave-it set end-to-end infrastructure changes. In fact I pressed > for divide-and-conquer thinking about this effort and it was been repeatedly > and vigorously rejected. > If I thought a divide and conquer approach would work here, I'd go with it - but I don't see it being a strong enough sell to the executives who make the staff allocation decisions at the companies that need to implement it until it solves enough problems that it's really compelling - hence wanting to have something which concurrently solves more than one significant issues (delayed bounces plus privacy protecting forwarders, "attribution of changes" as I called it, and replay elimination for properly authenticated mail) > To the extent that adoption by just two end systems can achieve benefit, I > believe there has been nothing said or documented to support that. It's not > that I'm disagreeing with your claim. It's that I don't see how it is true, > given what has been said, so far. > Also, it's not that I disagree that DKOR can be viewed as a subset of DKIM2. > It's that there has been no sense of how to operationalize a sub-setting of > DKIM2, nor does the documentation support doing that. > > > > > >> Both systems provide much less benefit if messages flow indirectly through a >> forwarder or mailing list that is not participating. > Less is not the same as none. > I agree, though as I mentioned above - less enough and there's no compelling reason to implement sufficient to overcome the activation energy. If I could use an analogy of electron excitation states - it takes a certain level of benefit to knock development teams off their existing course to build something new. I don't think DKOR has no value, just that it (the first draft at least) didn't have enough compelling benefit to justify implementation. > > >> DKIM2 provides an upgrade path where when the intermediate systems are >> upgraded to support DKIM2, every hop of the pathway is DKIM2 and you can >> eventually start requiring a full DKIM2 pathway to accept mail from more >> sites. I can anticipate a future DMARC-style technique for publishing a DNS >> record saying "do not accept messages from this domain that have exited the >> DKIM2 ecosystem at any point". > Consider the likely, and long-term, reality that only /some/ intermediaries > adopt it. How will that look, in terms of actual efficacy? > Pretty poor. Basically once a message exits DKIM2, all following hops have to fall back to treating it like the top-most hop is a regular DKIM1 signature. Hopefully the remaining intermediaries don't modify it. If they do, then we're back in the same situation as a failed DKIM signature. And of course, since it has exited the DKIM2 ecosystem then all replay protections are moot. > And I'm suggesting the consideration be in terms of detailed scenarios, not > just broad, generic reactions to the idea. I know some of the Google people have written up a bunch of the scenarios in more detail. I'm pretty keen to not try to "recover" a gap in DKIM2; instead I'd advocate pushing hard for modifying forwarders to implement it with punative filtering at the receiving end on one hand, and easy-to-use libraries and milters helping them to get DKIM2 working on the other hand. > Stylistically, it is of course fine to say that what it is trying to do is > not useful or is insufficiently useful, but these need to be explained in > detail, rather than just asserted. Especially when the thing being > criticized is not being offered as the only path to pursue.. > > DKOR has a more modest goal than DKIM2. As you note, it is a subset. > > If that subset of DKIM2 can, in fact, be considered as a real-world, > operational subset, then let's do that and compare just that portion of DKIM2 > with the same scope and goals as DKOR. I'd be happy to test DKOR as well; if there are people interested in doing so. It doesn't seem hard to implement. > And there is nothing about DKOR that is meant to limit pursuit of > /additional/ and complementary mechanism. Independently. I would be worried about producing too many options as the output of this working group, without clear indications of how they're supposed to work together. >> I agree that it's a potential stepping stone in the right direction, but by >> itself it's not sufficient. > ack. > > > > > >>>> Our approach solves the whole problem enough to be worth the effort. >>> You keep saying that. I keep asking for detailed scenarios that show how. >>> You then keep coming back witht he same, generic claims. >>> >> OK - let's suppose that I had DKOR headers on this email. >> >> Presumably my system would send two messages with DKOR headers; one >> MAIL-FROM: [email protected] >> RCPT-TO: [email protected] >> the other >> MAIL-FROM: [email protected] >> RCPT-TO: [email protected] > ... >> It's unclear from your draft whether the IETF mailing list server is >> expected to add its own MAIL-FROM and RCPT to headers to each email or not, >> but regardless... > The mailing list is re-posting mail. A new submission. It can do whatever > it wants. > > Except, of course, it must use new RCPT addresses, since that's its job. > > Whether it specifies a different Mail-From varies, but it is a common and > reasonable thing to do, since the originating site can't do anything about > delivery problems for addresses used by the mailing list. > > Making this a BCP-based normative requirement -- I'd suggest SHOULD rather > than MUST, just to deal with scenarios that don't need a different address > -- would be reasonable. > > But note that neither of these has anything specifically requiring a change > in signing technologies. > > Nor does a SHOULD that the mailing list add its own signature. It's not, though many lists do. Certainly a recommendation against changing message just because you can would be good, even though a delta mechanism would make changes less damaging to deliverability once all the remaining hops understood it. > >> there's no way for Gmail to know - if this was a spammy message, whether the >> spam was generated by me and sent to the IETF list, or whether the IETF list >> was a bad actor. It would need a reputation database. You've basically >> re-implemented the same problems that ARC has. > I'm going to claim that this is required, no matter what underlying tech is > used. > > Any scenario that matches on simple, objective, non-obvious criteria for > spamminess might involve a message that is actually legitimate. Feel free to > provide an analysis that comprehensively shows otherwise. However, to date, > after some decades, I think we have not seen it. That's not how any of the major providers think about spamminess. Individual messages are evaluated against a metric of "does the user want to see it" (by some level of dark magic); and spamminess of a source is evaluated against "what percentage of traffic from this source is unwanted". "Comprehensive analysis" is a red herring here; people don't share comprehensive analysis of how they evaluate messages, even in private. Demanding such an analysis isn't going to get us any closer to a useful place. >> With DKIM2, the second message would have on its copy from me: >> >> DKIM2-Signature: i=1; [email protected]; [email protected]; >> d=fastmailteam.com >> >> And then on its copies from the mailing list: >> >> DKIM2-Signature: i=2; [email protected]; [email protected]; >> d=ietf.org >> >> DKIM2-Signature: i=2; [email protected]; [email protected]; >> d=ietf.org >> >> DKIM2-Signature: i=2; [email protected]; >> [email protected]; d=ietf.org >> >> etc. Each with a separate signature, so they would be clearly not just a >> replay of a single message which was directed at the mailing list. > After reviewing this a number of times, over the last month, I've come round. > > > First, to the goal of supporting a chain of signatures and second to having > the signatures label the sequence. > > On the numbering sequence, it might seem obvious and trivial to add, but it's > use involves an extra bit of analysis mechanism and even trivial stuff can > get tricky, in the considerable scale and complexity of highly distributed > and independent implementations and erratic adoption. But overall, I'm > sufficiently swayed to include it in the next version of DKOR. The same numbering mechanism is in ARC, which - despite its feature gaps, has had some deployment. I did a rudimentary implementation over the couple of days of an IETF hackathon building on our DKIM library back in 2017 (which was then extended and improved to become the code we still run today at Fastmail). >> Even more importantly, they would have delta header fields: > Or not. > > Or, rather, they /might/ not. And for a very long time, probably won't. Sure, if we went the route of making it optional to describe your changes while making changes. I am strongly against that choice, but I understand that the working group may come to that consensus. > But that can be ok, unless an artificial dependency is created. Much like > DANE did with DNSSec. The dependency is strictly operational, but it was > written into the core DANE specification and constituted a show-stopper for > adoption. It's only artificial if you want to just reimplement ARC with DKOR-esque to/from additions. That's not crazy, but it also leaves a lot of the problems that ARC had with malicious sites prepending valid ARC headers from another email (can also be done with DKIM headers from another email - where the header validates but the hash doesn't match the headers/body, and fake Received headers to match) - then pretend that they got the bad content and just added a signature before forwarding it. Without delta mechanism, you can't tell that they're lying. > In technical and even operational terms, the delta mechanism is fully and > completely independent of the signing methodology. Signing needs to cover > the delta header field, but that's a mild operational convention, not a > technical design integration. I agree except for the parts where I think the value is high enough to require it. > To stress this point: The delta mechanism can be and should be pursued > independently of any changes to the signing tech. I understand and have sympathy with your point here while still disagreeing because of the (at least in my mind) huge value of requiring sites to document and take responsibility for their changes and not be able to lie about the message they received. >> If it detected DKIM Replay in the general case, it would not be trivial - >> however it only detects DKIM Replay in the direct case. > Given that Replay is about actions involving an intermediary, I don't know > what direct vs. indirect means. > > In any event, yes, there are legitimate scenarios that match Replay abuse > scenarios. > > And there always will be. Can you give some examples of legitimate scenarios that match Reply abuse scenarios (in a world where every site which sends you indirect mail is running DKIM2. I agree that until then, there will be scenarios that match Replay abuse) > So, yes, there is more needed to assess the difference. However I think the > view that this is somehow amenable to perfect assessment by strictly > objective, mechanical means is wrong and misguided, based on the industry's > experience over three decades. I am unpersuaded that it's not possible, but I could be persuaded by a scenario where it wouldn't work. >> It's still not possible to distinguish between an alumni forwarder and a >> DKIM replay; short of keeping a database of every alumni forwarder that >> points to you, and at scale that's decidedly non-trivial. > We've seen an example of using a Microsoft intermediary to commit DKIM Replay > spam. > > Every technical aspect of that looks to be legitimate. But the operational > practice was not. > > > > > >>>> because it doesn't close the forwarding hole and forwarding becomes even >>>> more of a poisoned chalice than it has already become (Wei showed evidence >>>> of this and a credible theory for why). >>> Scenarios, Bron. Show yours working in detail for all this extra benefit, >>> so others can a) evaluate what it will take to adopt it, b) evaluate its >>> likely efficacy, and c) consider being able to use different components >>> that might have superior characteristics. >>> >> >> See above a worked example. I'm happy to do more examples if that's still >> not clear enough. > Yes, please. > > I think ones that might be especially helpful would deal with paths that have > only partial adoption. They are interesting only in that they fall back to existing evaluation mechanisms, so I could write them up but it won't shed much light because it will just be "yeah, DKIM2 isn't providing > > >>>> This is my objection to your proposed approach. It's both trivial in its >>>> implementation, and trivial in its benefit. >>> Again, saying that making it easy to adopt and easy to use and effective >>> for finding Replay is a trivial benefit seems really quite surprising. >>> >> I reject the assertion that DKOR will be effective for finding Replay. It >> is indistinguishable from alumni forwarding or mailing lists, and provides >> no upgrade path to make it distinguishable. >> > Your rejection appears to be predicated on the view that I suggest DKOR be > the only action taken. But it isn't. > > I am suggesting it as an upgrade to signing activities, where the upgrade is > compatible with existing DKIM, rather than requiring a replacement of the > global DKIM infrastructure. > > Preserving an existing, widely-adopted, and useful infrastructure is not a > small benefit. Adding enhancements that rely on it and, therefore, are > compatible with it -- ie, enhancements that represent incremental benefit -- > are especially worthy. > > And the cost of replacement is pretty much always much bigger, in terms of > time, money, and effort, than is estimated. Advocates are pretty much always > wildly optimistic about the expected rate of change, when compared against > what actually happens. I would pretty much say the same thing except that my co-authors are from Google and Yahoo, organisations with a sufficiently large customer base that if they favour delivery from sites using strong authentication, that can drive faster change. So I remain more optimising that a compelling enough spec could drive faster change than usual. Bron. (plus in a year or two everybody will be able to vibe code DKIM2 support into their MTA in an afternoon with an LLM) -- Bron Gondwana, CEO, Fastmail Pty Ltd [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
