On Mon, Jan 6, 2025, at 14:46, Dave Crocker wrote: >> >> Key Changes: >> • Removed milestone dates >> • Simplified a lot of the supporting text >> • No mention of "trust relationships" >> • Used the words "hop" and "hops" to align with the terminology in RFC5322. > The word hop does not appear in RFC5322. > > I suspect you mean RFC5321. Unfortunately, it's use in the latter might be > confusing, since it does not distinguish between SMTP 'hops' -- ie, simple > MTA-MTA relaying -- versus a series of multiple posting/delivery sequences, > such with mailing lists, which produce a very different architectural > environment than simple relaying. >
As a recipient it's all the same to me, it came through a bunch of different systems which may or may not have > An example of the danger to design thinking here is that simple relaying > within a single posting/delivery sequence is supposed to be highly > constrained, with a goal of no changes to the author's message. By contrast, > a sequence involving re-posting intermediaries permits arbitrary changes to > the original message. > What does "designed to be" mean here? Nothing. Neither party in an SMTP transaction knows whether the other end is a simple relay or a complex mailing list; absent side-channel information. >> DKIM2 Draft Charter >> >> Background >> >> Emails often flow indirectly through multiple systems - at each hop >> potentially undergoing redirection, expansion into multiple copies via >> aliases and mailing lists, as well as rewriting and filtering before >> eventually arriving at a mailbox or being processed by a receiving software >> agent. > This opening sentence demonstrates the problem of failing to distinguish > between a classic SMTP-based single posting/delivery, versus more elaborate > scenarios with multiple deliveries in the sequence leading to a 'final' > recipient. > Maybe that's my recipient bias speaking, but - as the recipient you have no idea which of those it's come through or which of those it was intended to come through. This dkim2 thing is an effort to give you the information to distinguish those. >> >> Known difficulties caused by multi-hop email delivery include: >> • If a message is modified after DKIM signing, it is not possible to >> determine what was modified, or which hop made which changes. > Why is it important to know this? The draft does not say. > It's a working group charter, not a manifesto. > But since discussion on this list and elsewhere has explained this, I'll > respond to the expected explanation: > >> I believe the idea of being able to reverse changes, for the purpose of >> validating the original signature, is lacking any experimental, never-mind >> operational, experience. This a reason to treat this line of effort as >> research. And yes, I mean it qualifies as an academic research topic. >> >> And there is a social-level potential downside to such work: A design goal >> of being able to do this is likely to have the operational effect of >> marginalizing any types of changes done by an actual intermediary, such as a >> mailing list. So while the current email world is fine with a mailing list >> doing whatever it wishes to/with a message, this new, reversible world will >> likely treat non-reversible changes as misbehaviors, causing 'failure'. >> >> This problem of marginalizing otherwise-acceptable behaviors has already >> been demonstrated, with misuse of the word 'forgery' in email, and >> constraints on the values permitted in a number of address fields. >> >> • The SMTP RCPT TO address might not be present in the signed header fields >> of an email, meaning that the same message can be sent to arbitrarily many >> recipients, and those recipients can not tell if the signer intended to them >> as recipients. > If only it were possible to define a header field to hold this value and then > to develop operational expectations for its inclusion... Rather than, say, > inventing a whole new protocol. > Please explain the difference between "a header field and operational expectations for its inclusion" and "a protocol". I don't anticipate dkim2 changing anything about SMTP over the wire (other than: there's only one RCTP TO in the header so you can only include one RCTP TO in the SMTP transaction since any other address won't be aligned). So we're basically describing the same thing here; just using different words. > Previous discussions about replay cited this. (As I recall, I was one of its > proponents.) > > But I'll also note that the bullet specifies a consequence that is not > strictly correct. This is probably an artifact of not having explained > exactly what scenarios are of a concern. > > To preserve the original DKIM signature and to send to new recipients, as if > the message came from the original signer, requires a certain kind of > collusion between the original author and the misbehaving recipient, as well > as the misbehaving recipient's platform operator. > > This collusion with the original author is why I've noted that, really, the > actual Replay attacks that happen originate from failures of internal > controls at the original author's email platform. > Sure, if you take a really hard-line stance on "internal controls"; and you only allow for platforms with super well vetted customers who never have their credentials stolen. I too would like to live in that world. > A lack of vetting and accountability for those using that platform. Hence, > seeking public standards to respond to this is externalizing an internal > problem. > Now that's a strawman. I counter with RFC3514. All protections against misbehaving systems on the internet are just "externalizing an internal problem". >> • Similarly, a message with the exact same DKIM signature can be >> legitimately received by multiple recipients at a single domain, meaning >> that tracking signatures is not sufficient to determine whether a message is >> being replayed. > Either this bullet is, really, the same as the previous one, or I've no idea > what 'problem' is being claimed here. > > I've tried to formulate some guesses, but don't have confidence that any of > them is what you mean. > Some of the big mailbox providers track DKIM header hashes as a basic "is this a replay" protection; which works tolerably well, but only because they're collecting a database of known mailing lists over time - so they have heuristics about how many copies of the same message they expect to receive from different sources. It's another place where a new mailing list will run into scaling-up problems as their traffic gets dinged as replay at first, and an overall detriment to interoperability - but it's helped them cope with the very real problem of legitimately millions of the same message being sent to different addresses on their systems, none of which were listed in the headers. P.S. you could ask, if you're unsure about something I've described, or that that others have experienced, rather than guessing. It's OK to ask me questions if I haven't been clear, rather than just making statements. >> • The SMTP MAIL FROM address can be forged, meaning that accepting an email >> and later sending a DSN to that address can cause backscatter, making it >> hard to perform asynchronous content analysis or delay delivery while >> collecting more signal; leading to the use of greylisting as a suboptimal >> workaround to delay making a determination. > Since the SMTP Mail From is not a signature and since it is specified to > permit any address, no it cannot be 'forged'. > Again I think we're talking terminology past each other. I'm really happy to have a better term for "set to an innocent third party who gets backscatter. I will however note that Wikipedia says (currently) at https://en.wikipedia.org/wiki/Backscatter_(email): Backscatter occurs because worms <https://en.wikipedia.org/wiki/Computer_worm> and spam messages often forge their sender <https://en.wikipedia.org/wiki/Envelope_sender> addresses.[1] <https://en.wikipedia.org/wiki/Backscatter_(email)#cite_note-1> Referencing: https://ieeexplore.ieee.org/document/4550292 > On this, I have a better ability to guess at what is actually meant, but it's > better for the authors of the charter to make that clear. > > The caution that I will offer is to make sure that any claimed 'problem' is > described very carefully and that it describes an actual problem and that the > problem is demonstrably serious enough to warrant an international standard > at dealing with it. > > > >> Objectives >> >> The working group will extend and modify the mechanisms of DKIM to address >> message alterations, to provide signing of the intended recipient address at >> each hop, and to make asynchronous delivery status notifications usable. > As I noted before, the expected result will not be extending and modifying. > This is inventing an entirely new protocol. It reuses some DKIM components, > but the plan is for something that is architecturally and fundamentally > different. > > Also: I get accurate and useful delivery status notifications all the time. > So if there is an operational problem with them, it has not been described. > "It works for me so it's not a problem". Seriously Dave, this argument is not compelling. If you want to assert that backscatter isn't a thing, then I believe you're in the rough. >> It will be necessary for any new design to work in parallel with the >> existing mechanisms, and have a clear upgrade path. > There is no 'upgrade' between independent, incompatible protocols. There is > just adoption of the new and, possibly, dropping the old. > > If someone thinks otherwise, then please provide a substantive explanation. > Side-grade. Conversion. Replacement. Adoption. I don't care about the terms here. I believe it will be compelling and lead to an eventual dropping of the old. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
