+1 that this charter is greatly improved and ready for review. That said, one largish and one smallish comment below
On Mon, Dec 30, 2024 at 9:02 AM Tim Wicinski <tjw.i...@gmail.com> wrote: > Hi > > I think V3 is worth having the IESG work over. > > I made one small change > > s/intended to them as recipients/intended them as recipients/ > > tim > > > On Sat, Dec 28, 2024 at 9:31 PM Bron Gondwana <brong= > 40fastmailteam....@dmarc.ietf.org> wrote: > >> Based on Dave and Murray's comments in particular, here's another take! >> >> 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. >> - Detailed known issues, and specified the three major issues being >> addressed explicitly: modifications, lack of signature on recipient, lack >> of signature on sender/bounce address. >> >> The detail of known issues is maybe a bit wordy - would be happy to see >> tighter text proposals. >> >> Again - the original is at: >> https://notes.ietf.org/YGynIPpYS7yqg5G7ZeSQeA?both >> >> Cheers, >> >> Bron. >> 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. >> >> 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. >> - 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. >> - 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. >> - 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. >> >> 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. >> > First, consider that in addition to addressing alterations, that the specification identifies which hop made which modification. This is to speak to the first bullet in the Background. > It will be necessary for any new design to work in parallel with the >> existing mechanisms, and have a clear upgrade path. >> >> To achieve its goals, this work requires a wide scope. The group may need >> to supersede, modify, or replace many parts of the current email >> infrastructure and associated reporting mechanisms. >> >> To allow for widespread adoption, proposed solutions will be tested for >> interoperability and scalability. >> >> Deliverables >> The working group will produce multiple documents, at least: >> >> - A overview document describing the problem area and proposed >> mechanism (informational) >> - One or more documents on implementation of the mechanism (standards >> track) >> - A guide for implementation during the changeover period, in which >> interoperability with existing mechanisms needs to be maintained >> (informational) >> >> This working group will also liaise with the DMARC working group on >> adding our specification as a new recognized authentication mechanism. >> > Second, I prefer the prior language, as it empowers the DKIM2 working-group-to-be to update to the DMARC RFC to use the DKIM2 authentication mechanism. My worry is that DMARC working group is not chartered to do anything with DKIM2, and worse yet has language to preclude development of new authentication methods i.e. "[DMARC WG] will not develop additional mail authentication" in its charter that will cause confusion in the future. Because the DKIM2 specification is meant to tackle multi-hop flows that is problematic for DMARC when using the existing SPF and DKIM specifications, I think it is important for DKIM2 to be able contribute to better handling of these flows with DMARC. That all said, I think it's even more important that this work get started, so I don't think my comments should hold up sending this to the IESG. -Wei > >> Milestones >> >> - Overview document adopted >> - Mechanism document draft(s) adopted >> - Experiments and updated drafts >> - Implementation guide adopted >> - Group of related documents sent to IESG >> >> >> >> -- >> 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 >> > _______________________________________________ > Ietf-dkim mailing list -- ietf-dkim@ietf.org > To unsubscribe send an email to ietf-dkim-le...@ietf.org >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
