On Fri, Jan 24, 2025 at 5:51 AM Dave Crocker <d...@dcrocker.net> wrote:
> An Internet message (email) may, from creation to final delivery, pass > through multiple intermediaries, some of which simply handle and route the > message, others affecting an interim delivery and re-injection into the > ecosystem. There are complexities with this handling model, such as > evaluation, filtering, intentional mutation, and even malicious activities. > > A basic problem, throughout this entire discussion, has been the effort to > treat simple relaying through MTAs, and a multiple-posting/delivering > forwarding sequence such as with mailing lists, as the same thing. > > They aren't and never have been. > > Treating them the same is a fundamental architectural change, at best The > above language hides this reality. > > Mailing lists managers are not MTAs. Not architecturally, not as software, > and not operationally. > I'm not clear on what you're suggesting is wrong here. You're correct about the operating reality, but this text doesn't try to treat them as the same. Rather, it explains that this is a complex space with different agents doing different things. In fact the construction is "some do X, others do Y, all as part of the broader email ecosystem". > The core email protocols do not provide for authentication of the > identities in the message > > "identities in the message" is too broad and too vague. A random name in > the body is not relevant, but this language would include it. > > I suggest the reference be more explicit and constrained, such as: > > "identities recorded for authorship, receipt, or handling of the message". > > (quibble: we keep saying identities when we usually mean identifiers. at > the least, this is an example of the need to be a lot more careful about > language.) > Fixed. > > or evaluation of the content for any sort of validity or safety. > > I have no idea what providing for evaluation of the content for validity > or safety means. Nor, I believe, is there any widespread history of > discussion of that, in those terms. > > I suggest breaking this point out and writing something very different, to > set up the concern. (I don't understand the am not sufficiently clear > about what is intended here to be able to draft possible wording.) > I mentioned elsewhere, and we mentioned in STD 76, that a valid DKIM signature provides no guarantee, express or implied, that the message contains something that is objectively true or safe to open. This text is meant to remind the reader that email (even with DKIM) offers no such protection. > > DKIM [STD 76] extended the basic messaging function > > No it didn't. It added a useful feature to the messaging landscape but is > not part of 'basic' messaging. Perhaps: > > DKIM [STD 76] defines a means of associating a domain name with a message > stream and validating its use. This permits evaluating the stream, with a > high probability the owner of that name has some responsibility for the > handling of the message. > > There is a continuing mis-statement that DKIM validates the 'source' or > the 'sender' or the 'author' of a message. It does none of that. Really, > it doesn't. > I don't think the proposed text contains such a claim. It only says that the message was unmodified between the signer and the verifier, and that a specific domain name was associated with the signer. I think your proposed text says essentially the same thing, though with additional detail. I've replaced mine with yours. > The assertion does describe the signing behavior of some platforms, but it > is not DKIM's semantic, nor does it cover the behavior of all signers. > What behavior is not described? > Note for example that when a message passing through a handler like > Proofpoint, they might sign the message as it passes, but they are not the > source or sender or author of the message. > The replaced text didn't claim anything about the source, only the signer. > > by providing assurance that a message was not modified between a signing > agent and a verifying agent by affixing a domain-specific signature. > > DKIM makes no such assertion, and it is not true as stated here. > The cryptography involved would fail if the message was modified between signer and verifier. If the signature validates, the only conclusion is that the covered content wasn't modified. > All DKIM was designed to do was to reliably and authentically affix /some/ > identifier to /some/ parts of a message. This creates a noise-free message > stream that uses the identifier. > Agreed. > A side-effect of DKIM's technology is that the fields that are covered by > the signature -- and only those fields -- are protected in transit. > > Other portions of the message are not. > Also agreed. So is the issue here that the original text didn't mention the "covered" part? The proposed (now new) text doesn't either. > > Still, there exist known shortcomings in the email model that DKIM alone > is not designed to address, including the following: > > There are additional needs. They are new. Or, at least, they were not > previously a priority. Since they were not needs when DKIM was developed, > they are not 'shortcomings'. > > https://dictionary.cambridge.org/dictionary/english/shortcoming > > When something goes beyond a design goal, it is not reasonable to > characterize what is now needed as a failing of the existing system. > > If you have a two bedroom house and the family grows so that the family > needs more bedrooms, the problem is not a 'shortcoming' of the house, but a > changed demand by the family. > > dictionary.cambridge.org > > shortcoming <#m_418004886078517608_> > > SHORTCOMING definition: 1. a fault or a failure to reach a particular > standard: 2. a fault or a failure to reach a…. Learn more. > > 🔗 https://dictionary.cambridge.org/dictionary/english/shortcoming > <https://dictionary.cambridge.org/dictionary/english/shortcoming> > > > > Focus the concern where it belongs: a new set of requirements. > NEW: There are contemporary issues, not concerns at the time of STD 76 or earlier standards, that the community now seeks to address, including the following: > > * There is a desire to confirm that a message received truly originated > from, or with the approval of, the identity claiming to have done so. > Mutations of a message in transit interfere with the validity of DKIM > signatures, which stymies such efforts. If a message is modified after > DKIM signing, it is generally not possible to determine what was modified, > or which agent in the handling chain made which change(s); these would be > useful inputs to a more robust evaluation. > > Perhaps: > > There is a desire to maintain validation of a message's signing > identifier, across common transit and forwarding modifications. When a > message goes through a re-posting, such as through a mailing list, the > validation signature typically does not survive and cannot be recovered. > > The idea of annotating reversible changes is in the weeds of solution > space, not the basics of need. > > While mentioning a possible solution path might be useful, taking the > ability to do something that has no operational history at scale as > something implicitly expected and necessary is problematic to the health of > a working group. > Done. > > * A DKIM signature is independent of the true set of (envelope) recipients > of the message, > > 'true'? DKIM has nothing to do with recipient addresses, as such. > Correct, and this bullet is acknowledging that this disconnect exists. > Instead of casting this as a DKIM issue, cast it as a new functional > goal. Because it is. > > meaning that the same message and signature can be sent to arbitrarily > many recipients, across one or many independent injections into the > ecosystem, and those recipients can not tell if the signer intended to > include them as recipients. > > The charter needs to define DKIM Replay, since the term is over- and > mis-used, to claim a scope of concern much broader than reasonable. So, > > DKIM Replay exploits the absence of a protected recipient address, wheret > an authorized user of a site sends a message that is signed by that site, > to a collaborating receiver than then re-sends the message to other > recipients, not in the original set of recipients, but without any > indication that the message has been re-posted. This way, the domain name > of the DKIM signature is intended to result in a positive reputation > analysis that will obtain deliveries that otherwise would not succeed. > Note that the author of the message is authorized by the site with the > author domain. > > I included a slight variant of this that drops the ending sentence because the first bit already declares that the user was authorized. > > Objectives > > The working group will observe the success of current technologies, > primarily DKIM, reusing its techniques where applicable, to develop a new > technology suite that seeks to address these concerns. Early experience > from the deployment of ARC [RFC 8617] will also be considered. In > particular, this technology will: > > Rather: > > The working group will pursue incremental enhancements to DKIM and/or DKIM > use, where possible. It will pursue parallel or replacement mechanisms > only where incremental change is not feasible. > > Included a variant of this, as discussed elsewhere in this thread. > > * Provide stronger assurances against unauthorized use of the (envelope) > sender, reducing the success of direct domain name misuse and improving the > value of delivery status notifications; > > The concept of authorized use of the Mail From exists in SPF and nowhere > else. As such, the premise of this objective is problematic. > This is the most novel part of this proposal, to be sure, but I don't believe that disqualifies it as a goal. I think the move here is to slightly soften the previous bit to fall short of making this a hard objective. (The alternative is to require rechartering if we decide this is actually intractable or not a good idea.) > > * Identify message mutations made by any handling agent; and > > I suspect this means identification of common mutations, rather than all > mutations, since there is no limit to the latter. This text needs > elaboration, for clarity and precision. > I'm a little worried that leaving this open to the idea of being able to describe an arbitrary mutation will heap onto the complexity and time-to-specify this part of it (it feels very open-ended), but I'm apt to leave that decision to the WG. > > * Attach annotations in transit of the intended chain of handling to > assure accountability for each delivery. > > Attach annotations specifying changes that were made in transit, as part > of an authenticated chain of handling, to aid accountability of a > message's handling > > That change renders this bullet and the prior one very similar. The second is to identify (reversible?) changes made in transit; the third is to state that in the handling chain from A to B to C to D, A annotates that it intends to route to B, B to route to C, and C to route finally to D, so that if the message suddenly claims handling by some E, we've had a problem. I've left it unchanged for now. > The working group will strongly prefer output that, when deployed, does > not disturb the deployed ecosystem. > > Given the presumption of DKIM replacement, this sentence is surprising. > With the incremental approach I'm advocating, it might be reasonable to > retain. > I think this is important to leave in. Whether this work goes the incremental or full upgrade route, it shouldn't suddenly cause STD 76 to stop working nor should it break any other part of the messaging stack. > > It may, however, through the normal course of evolution, replace > technologies such as DKIM and ARC. > > The draft specification this work is currently based on requires > replacement. > That could change. > > To allow for widespread adoption, proposed solutions are expected to be > robust in terms of interoperability and scalability. > > I believe there are no IETF specifications lacking this as a requirement. > As such, it isn't meaningful to include, absent some sort of technical > details' being required or metrics attached. > In my experience many discussions in this general community can wander in the opposite direction too easily. Sometimes polite steering by participants or chairs isn't enough to wrap these up quickly. This is a reminder that if you're not pushing an idea that meets these basic bars, you could be summarily shut down, and the charter supports it. If people don't think this is helpful, I'm happy to remove it. > > > Deliverables > > The working group will produce multiple documents: > > * An overview document describing the problem area and proposed mechanism > (Informational) > > * One or more documents on implementation of the mechanism (Standards > Track) > > huh? A standards track document about implementation? Seems odd. > I suspect what is meant a /specification/ of the required mechanisms. > Alrighty. > > > * An Applicability Statement guiding implementation during any deployment > period, in which interoperability with existing mechanisms needs to be > maintained (Standards Track) > > Given that 'implementation' is an ambiguous term, differently referring to > writing code, versus deploying, I suggest not using the word. I think the > intent here is "guiding deployment and use". > > > Done. I'll post v5 in the morning absent any adverse feedback on this thread. -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
