Hi Bron, This charter looks very good, but.. I think it is missing to address explicitly the following pain points: key rotation and cypher upgrades.
It speaks about the transition from DKIM1 to DKIM2, which is very good, but it should build upon this to ensure a constant evolution of the cyphers and keys are possible. One nit, that can be addressed in one of the outcomes: DKIM2 best DNS practices. Already keys fit barely in a 1500 bytes packet, when billions of emails are exchanged a 0.1% DNS error in retrieving a key is a lot of emails not authenticated. A last nit, many standardized on opendkim, because of interoperability. There were too many weird things happening between different implementations of DKIM1. I don’t know if interoperability should be better addressed (better debugging, reporting), or the suggestion that everyone should use the same library. Keep the good work. From: Bron Gondwana <brong=40fastmailteam....@dmarc.ietf.org> Date: Thursday, November 7, 2024 at 07:57 To: Murray S. Kucherawy <superu...@gmail.com>, Bron Gondwana <brong=40fastmailteam....@dmarc.ietf.org> Cc: ietf-dkim@ietf.org <ietf-dkim@ietf.org>, Wei Chuang <wei...@google.com>, Richard Clayton <rclay...@yahooinc.com> Subject: [Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2 The proposed charter text has been workshopped by a few people already, but I would also welcome any comments here. For posterity, here's the current proposed text (for ease of quoting individual paragraphs in responses): DKIM2 Draft Charter Attribution of email is made difficult by the exact properties that make email valuable as a technology - a heterogeneous network of systems with different owners, different software, different update lifecycles - and of course different bugs! Emails also often flow indirectly through these networks, 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. DKIM gave us good tools for attributing the source of messages that were not modified between originator and destination. Several attempts have been made to address the issues that arise with intermediaries. For various reasons, these technologies have failed to fully address the issues that arise when changes are legitimately made or when bad actors alter or replay messages, and we do not have well-specified mechanisms that ensure that error reports reach all the entities that need to be aware of them. This working group will take a holistic approach to the underlying problems of attribution, error signalling, and trust relationships between the entities involved in handling an email - from its inception to arrival at its final destination. The working group will use the mechanisms of DKIM as a basis, extending it to solve the problems that have been identified in real-world usage. It will be necessary for any new mechanism to work in parallel with the existing attribution mechanisms, and have a clean upgrade path. This work will have a wide scope and the design may supersede, modify, or replace many parts of the current email attribution techniques and associated reporting mechanisms - while retaining the ability to support the same use-cases. To gain widespread adoption, it is expected that design proposals will be tested during the development of specifications. The working group will favor designs that are tested at scale and may dismiss those that are not. This working group will produce the following document(s): * A design overview describing the problem area and proposed mechanism * An algebra for describing how to reverse common changes to email content * A specification for authenticated email flow through multiple sites. * A specification for error and bounce handling with the authenticated email flow. * A best practices guide for implementation during the changeover period, in which interoperability with existing standards needs to be maintained. This working group will also update the following existing document(s): * DMARC to add DKIM2 as an additional authentication mechanism ... As the lead author on this text, obviously I like it! We could bikeshed a little to remove "dkim2" naming and just say "the new protocol" instead, and replace "DKIM" with "the existing specifications" or something. Bron. On Thu, Nov 7, 2024, at 14:42, Murray S. Kucherawy wrote: On Thu, Nov 7, 2024 at 12:27 AM Bron Gondwana <brong=40fastmailteam....@dmarc.ietf.org<mailto:40fastmailteam....@dmarc.ietf.org>> wrote: We have a draft charter here: https://notes.ietf.org/YGynIPpYS7yqg5G7ZeSQeA I've loaded that text into the datatracker for DKIM, and move it to "Draft Charter" state: https://datatracker.ietf.org/doc/charter-ietf-dkim/ Comments from people in this audience on the proposed new charter would be very welcome. We should have some of that discussion before I start the IESG internal and then external review steps. -MSK _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org<mailto:ietf-dkim@ietf.org> To unsubscribe send an email to ietf-dkim-le...@ietf.org<mailto:ietf-dkim-le...@ietf.org> -- 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