Catching up on this thread, but not in order: On Sat, Jan 25, 2025 at 10:12 AM Richard Clayton <rich...@highwayman.com> wrote:
> >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. > It's meant to indicate that in the presence of a valid DKIM signature, setting aside for the moment who signed it, one cannot infer that the content of the message is objectively true nor that it is free of any sort of software attack. The only thing you know is that from the signer to the verifier, it was unmodified. As Dave pointed out, you also are told as part of this result who the signer was. > >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.) > > This part of the charter is I assume meant to put assessing the safety > of an intermediaries change out of scope -- the proposed DKIM2 design > merely records what the change was and provides a robust way of knowing > which entity made it (so that one might hang some reputation on that > entity in an out-of-scope manner). > In that sense DKIM and DKIM++ are the same; you might know who signed it or where it was mutated and how, but you have no idea whether that mutation was something -- to borrow a term from the A-R RFCs -- "acceptable to the verifier". > >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'. > > they may not have been perceived to be shortcomings then -- they are > now, which is why a number of people wish to improve things for the > people whose email they handle > I think it's reasonable then to identify in the charter that things have changed since DKIM, and make it clear that we don't consider these to be defects. I'll modify the text accordingly. > >> 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. > > this is recipe for spending a considerable amount of time arguing about > exotic changes to existing fields and will result in complex and hard to > maintain code that has to handle two (or more) interpretations of header > fields in parallel. This heats up the planet to no purpose (let alone > heating up the tempers of WG participants) > > if the engineers (including myself) who have been debating these issues > (for most of a year now) thought that simple mods to DKIM1 were a good > way forward that is what we would have proposed. > Two things: (1) As to the suggestion itself, I think I'm undecided about whether this WG should be compelled to explore and dismiss extensions to DKIM versus going directly to a new thing. If I have to decide right now, I would include it as a suggestion but not a requirement. I can propose some text of that nature for us to try on. (2) I hope that the latter paragraph isn't meant to suggest that X people looking at this problem for Y time in some outside closed forum Z is meant to inoculate the proposed work from alternative suggestions. This is an open standards body. > >> * 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. > > I think the text in the charter is meant to nod towards the DKIM2 notion > that DSNs should not be sent to the envelope sender but "back along the > chain" and hence various mangling of MAIL FROM that is used to direct > DSNs to an appropriate entity will no longer be required > Yes; if I didn't capture it correctly, I'm happy to see suggested alternatives. > >> * 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 didn't think "clarity and precision" were required for a charter, > merely an indication of what was or was not in scope. Identifying all > mutations is clearly in scope ... being able to "undo" them may be too > complicated to consider (and self-defeating --- an intermediary that > redacts sensitive information or removes malicious attachments will not > wish a recipient to be able to undo their changes) > I think both are true: Clarity and precision about what is [not] in scope is a requirement. I suggest that all transformations are describable, otherwise software couldn't do them. But not all transformations are reversible (e.g., compression, or anything else that's lossy). I think we're only interested in reversible ones. So does the working group want to spend time exploring the notion of "any possible reversible transformation", or would we rather confine ourselves to a small (perhaps extensible) set of common ones known to be reversible? The latter group is constrained and certainly tractable; the former group is infinitely larger and a general solution will require more time to nail down (or decide we can't). -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
