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

Reply via email to