On Thu, Dec 12, 2024, at 08:59, Murray S. Kucherawy wrote: > I've uploaded the charter text at the top of this thread to the tracker (not > the one from 11/27 yet). I wanted to do another round trip on some of Dave's > points.
Happy to. I realise I had a draft which already hopefully addressed some of the points sitting in my mailbox from before I went on vacation in mid-December, and then I didn't get back to it before Christmas. > I am not concerned with milestones yet. The text is far more important. Agree. > On Wed, Nov 27, 2024 at 4:15 PM Dave Crocker <d...@dcrocker.net> wrote: >> __ >> Summary: >> • As provided, this is an extremely broad and extremely vague statement of >> work. It continues to sound far more appropriate for the IRTF than the >> IETF, especially absent a concete draft specification to take as input. >> (It's not as if the IETF hasn't accepted charters like this. But it /is/ as >> if such working groups have typically not fared well. Stated more baldly, >> "let's charter a group and then figure out what we are going to do" has a >> bad history in the IETF.) > > Bron (or anyone involved), do we have any initial documents to propose > formally in the charter? The two I've published so far: motivation (which includes some design) and delta. I have a task to write up bounce handling, but there's still design work to be done there which I expect would happen inside the working group because some of it is going to be bikeshed painting, but also hopefully based on input from people who have written bounce parsers about what would be easiest / most compatible for them. The key concepts are: • Bounces go back through the path, so a message that went A -> B -> C -> D bounces back via D -> C -> B -> A, allowing asynchronous DSNs to be reliably sent for messages where the last-hop signature validates. • The format needs to be easy to unwind, such that D could reject the message via privacy-preserving gateway C, and C could format the DSN such that it looked to B as if C had sent a delayed bounce itself; with no evidence that D exists. • The bounces should be signed; so the bounce from C to B is signed by C's key, and contains B's original signature on the outbound message, so B can confirm that it both transited the message in the first place, and the bounce is coming from the same domain that it sent the message to next. With those concepts, the key parts to write up are: • Time limits on each part (you can only bounce messages within say, a week of receipt, total, all the way back the chain) • An RFC3464 extension to reliably machine-encode the necessary fields in the DSN. >> • The draft seems to include a target of 'trust relationships' which is an >> open research topic that DKIM only indirectly relates to, except for >> trusting a signature. > > DKIM benefits from trust relationships, as does any other authentication > protocol, and is of limited use without them, but pays very little attention > to them in text because they are the purview of an implementation's "special > sauce". If there's a clear intent to develop an interoperable notion of > trust relationships (i.e., reputation), we should say so explicitly, > otherwise I suggest that we should avoid the topic or, at a minimum, leave it > to a post-rechartering topic. As I said in my other message, happy to drop "trust relationships" from the charter text. >> • IETF Internet Mail handling really only covers a single posting/delivery >> sequence. It touches on more elaborate sequences, but only piecemeal. And >> draft charter does not really note or deal with this difference in scope. So >> the proffered 'holistic' effort is a very considerable increase in scope >> from something labeled DKIMbis or DKIM2. > I concur, though I don't believe this is a showstopper, is it? Maybe we just > need to be more explicit that the scope here is to try to carry > authentication information from injection through delivery and every > intermediary in between. If it wasn't clear enough from my proposed text, then - as I suggested in my reply to Dave - I'd love to see proposed text. It's definitely a necessary part of the intent here. >> >> Detailed comments: >> >> >> >> >> >>> DKIM2 Draft Charter >>> >>> ** <https://notes.ietf.org/#Background>Background >>> >>> Emails often flow indirectly through multiple systems, 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. >>> >> >> >> The opening sentence sets a stage that matches many end-user experience >> views of email, but misses the basic technical distinction that is the >> essence of the enhancement being sought. *As described in that sentence, >> email is delivered more than once, before it is 'finally' delivered.* >> >> So instead, perhaps: >> >>> It is common for an email to go through multiple posting/delivery >>> sequences, before eventually arriving at a 'final' mailbox or being >>> processed by a 'final' receiving software agent. Examples of such >>> 'indirect' flow include redirection through an alis, expansion into >>> multiple copies via an alias or a mailing list, as well as rewriting and >>> filtering before eventually arriving at a mailbox or being processed by a >>> receiving software agent. >>> > > Would like to hear other opinions of this. >>> >> I left 'rewriting' in but actually don't know what it refers to, nor why >> 'filtering' is relevant to DKIM signature survival. >> >> (By the way, I thought that posting from an ESP was also classed as an >> indirect flow. Is this not correct?) >> > I presume "filtering" includes any sort of stripping of material an > intermediary or edge MTA might consider to be worth stripping for whatever > reason (e.g., malformed header fields) but I agree that an example might be > helpful to clarify. > > I imagine "rewriting" is there for any of a number of reasons. Very early on > in my email career I used to see things like m...@example.com used externally > but it was rewritten (unnecessarily, it turns out) to m...@host.example.com > prior to delivery when the main ingress server figured out which host was > mine. There are probably more apt modern examples. > >> >> >> >> >>> DKIM provides a way to detect that the content of a message was not altered >>> between the signing domain and its eventual destination. >>> >> This sounds correct but can be misleading, given the 'eventual'. > > ...between the signer and any verifier? "Between the signer and all following recipients"? >> DKIM was designed to work from one posting to one delivery. It was never >> intended to survive the vagaries of what can happen between a delivery and a >> next posting. That it sometimes does survive is nice, but was not a design >> goal. >> So what is being sought here is a very basic and very substantial increase >> in scope for DKIM. >> > Is this another example of what you described above as the perceived use case > vs. what's actually happening? > > Perhaps: > > "DKIM provides a way to detect that the content of a message was not altered > between the signer and a verifier, even if this requires one or more > intermediate deliveries and re-injections." Sure, that would work. >> >> >>> Several attempts have been made to address the issues that arise with >>> alterations made by intermediate systems. For various reasons, these >>> technologies have failed to provide the information to reliably distinguish >>> between legitimate mail, and replay or alteration of messages by bad actors. >>> >> DKIM does not attempt to distinguish 'legitimate' mail from mail that is not >> legitimate. > > From the use here, I infer "unmodified since injection" to cover content and > something about the original, intended recipient set to cover replay. >> >> >> As for 'replay' it needs to be precisely defined here, especially since >> there are different views about what it refers to. >> > +1 All the definitions are kinda wooly because a bad actor might be any of the various parties involved, but my internal working definition is something like "intentional delivery to an SMTP RCPT TO address in which the mail flow was not intended by the sending signer and the recipient". This excludes the "privacy protecting relay" case, where an email to priv...@relay.example.com is forwarded to me, so the sender doesn't know that it's coming to me, but as the recipient I expect to receive email there, and it also excludes the case where the sender deliberately BCC'd me but I didn't know it was coming - and was unable to see that message was intended for me. It's the fact that you're unable to distinguish whether the sender intentionally BCC'd a message to you or not that makes it very hard to separate intentional BCC from fraudulent replay, and which DKIM2 is designed to provide more information about. >> As for alteration by bad actors, I was not aware that that is considered a >> problem for DKIM. In fact I thought it was /not/ a problem. So this needs >> to be explained and documented. >> > This gets to "acceptable" mutations, whatever that means. Or "innocent", > maybe? Agree, it's not a problem with DKIM (except in the l= case where DKIM isn't functioning as intended); it is indeed that acceptable/innocent mutations can't be distinguished. >> There are problems with error handling? What are they? I don't recall >> seeing discussion of this. What is the actual work to be done? What goals >> for improvement are sought? > > +1 I addressed this above: the problem with error handling is that bounces are unverified; both the SMTP FROM being falsifiable, meaning you can cause them to go to the wrong place, and the lack of signatures on the bounce meaning that if you get the content of a message you can falsify a bounce back to the sender, misleading them about whether their message was received (e.g. cause people to be unsubscribed from a mailing list). The second isn't a big problem currently, but it's worth closing the hole. >> Trust relationships are far -- very far -- beyond the scope of DKIM, other >> than whether a DKIM signature can be trusted. >> > I think it's fine to discuss how trust relationships might couple with DKIM > to impact handling decisions, but how to develop or track trust is probably > rightly out of scope (unless someone has something in mind). Happy to remote the text "trust relationships" from the charter. >> Given the considerable increase of scope for DKIM and range of topics cited >> here for improvement, the charter should have a concrete proposal to take as >> input, if only to provide an example of how one might approach dealing with >> these topics. >> > I would prefer a good starting point as well. I've given some more detail about the bounce handling up above; just haven't had a chance to write it up as a formal doc yet. >> >> >>> The working group will use the mechanisms of DKIM as a basis, extending and >>> modifying them to solve problems that have been identified in real-world >>> usage. >>> >> Since they have been identified, they should be documented here, clearly >> enough to aid the working group in knowing whether something is in-scope our >> out of scope. > > +1 I'll formalise them a little more and put in the notes.ietf.org version then re-post here. >> >> >> >> >>> It will be necessary for any new design to work in parallel with the >>> existing mechanisms, and have a clear upgrade path. >>> >> If it is parallel, it is independent. So I don't know what it means 'to >> work' in parallel. And I don't know what it means to not work in parallel. > > I imagine the intent is not to disrupt the deployed DKIM base while DKIM2 (or > whatever) is being developed or deployed. >> >> >> >> >>> To achieve its goals, this work requires a wide scope. The design may >>> supersede, modify, or replace many parts of the current email >>> infrastructure and associated reporting mechanisms - while retaining the >>> ability to support existing use-cases. >>> >> Oh. In parallel with existing /email/. You want to replace the current >> Internet Mail infrastructure. Gosh... >> >> >> Forgive me, but, again, this is something for the IRTF, not the IETF. >> > I'm not convinced there's an IRTF project to charter here; this feels IETF-y > to me. I do think, if anyone's actually built and tried this already, I'd > love to hear what the result is after even a brief trial. We expect to trial this in parallel with the working group! I've built some little components (as have at least Richard, and possibly others) but not a full end-to-end version. 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
