[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Wed 20/Nov/2024 03:09:19 +0100 Steven M Jones wrote: On 11/20/24 06:43, Murray S. Kucherawy wrote: On Mon, Nov 18, 2024 at 9:11 AM Dave Crocker wrote: On 11/6/2024 6:54 PM, Wei Chuang wrote:     "message algebra This topic has been a point of fascination for some years. It is, indeed,

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Mon, Nov 18, 2024 at 9:11 AM Dave Crocker wrote: > On 11/6/2024 6:54 PM, Wei Chuang wrote: > > "message algebra > > " > > This topic has been a point of fascination for some years. It is, indeed, > attractive

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 11/20/24 06:43, Murray S. Kucherawy wrote: On Mon, Nov 18, 2024 at 9:11 AM Dave Crocker wrote: On 11/6/2024 6:54 PM, Wei Chuang wrote: "message algebra " This topic has been a point of fas

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Mon, Nov 18, 2024 at 9:04 AM Dave Crocker wrote: > On 11/6/2024 6:54 PM, Wei Chuang wrote: > > signed recipient > > Small request for clarification: > > I'm not familiar with this term. And the 'strong protections' paper you > cite does not seem to use it. > > Since recipients don't do the si

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 11/6/2024 6:54 PM, Wei Chuang wrote: "message algebra " This topic has been a point of fascination for some years.  It is, indeed, attractive. It is also a research topic, absent a body of experience show

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 16 Nov 2024, at 13:30, John Levine wrote: > It appears that Murray S. Kucherawy said: >> A small operator or individual with a good idea that lacks the resources to >> test at scale shouldn't be excluded unnecessarily. Are the large operators >> reasonably willing to test promising ideas eve

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 11/6/2024 6:54 PM, Wei Chuang wrote: signed recipient Small request for clarification: I'm not familiar with this term.  And the 'strong protections' paper you cite does not seem to use it. Since recipients don't do the signing, it is not safely intuitive to guess what the term means.

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Sun 17/Nov/2024 11:30:09 +0100 Laura Atkins wrote: On 16 Nov 2024, at 10:39, Alessandro Vesely wrote: On 15/11/2024 20:13, Dave Crocker wrote: You might prefer more comfortable language but I was characterizing the very problematic tone that I perceive permeating work in this space, in rec

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

Hi Dave, Sorry for the delay in replying to this - I've been traveling back from IETF in Dublin. Thanks for this very detailed review! I think there are three key significant issues that you've raised here: * whether this is DKIMbis or a broader thing * the timeliness of bringing this work to I

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Laura Atkins writes >Now, it was, so it was fine. But it does suggest that anyone can >create a Quickbooks account to impersonate my company. Because >Quickbooks sends from their own domain, it’s all DMARC passing >mai

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

> On 16 Nov 2024, at 10:39, Alessandro Vesely wrote: > > On 15/11/2024 20:13, Dave Crocker wrote: >> On 11/15/2024 10:55 AM, Alessandro Vesely wrote: >>> On 13/11/2024 21:14, Dave Crocker wrote: While 'indirect' has well-established context in many email technical circles, I believe

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

Richard Clayton wrote in : |-BEGIN PGP SIGNED MESSAGE- |Hash: SHA1 | |In message <20241116204935.dCb0mQcG@steffen%sdaoden.eu>, Steffen |Nurpmeso writes | |>Having said that, if it is really acceptable to include the entire |>history of changes in that "stack" that email headers fo

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <20241116204935.dCb0mQcG@steffen%sdaoden.eu>, Steffen Nurpmeso writes >Having said that, if it is really acceptable to include the entire >history of changes in that "stack" that email headers form (hihi: >yes please, i find it absurd that

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

It appears that Murray S. Kucherawy said: >A small operator or individual with a good idea that lacks the resources to >test at scale shouldn't be excluded unnecessarily. Are the large operators >reasonably willing to test promising ideas even if they're not their own? Based on private discussi

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

Alessandro Vesely wrote in <34f44d43-09f1-4dbb-9b9e-11391a022...@tana.it>: |On 15/11/2024 20:13, Dave Crocker wrote: |> On 11/15/2024 10:55 AM, Alessandro Vesely wrote: |>> On 13/11/2024 21:14, Dave Crocker wrote: |>>> While 'indirect' has well-established context in many email technical |>>

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 11/16/2024 2:39 AM, Alessandro Vesely wrote: DMARC's alignment requirement is an attempt at capturing the concept of legitimacy. It is an attempt at defining and constraining a very specific kind of limited legitimacy. Yup, it is successful as it catches a good deal of cases, direct mail

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 15/11/2024 20:13, Dave Crocker wrote: On 11/15/2024 10:55 AM, Alessandro Vesely wrote: On 13/11/2024 21:14, Dave Crocker wrote: While 'indirect' has well-established context in many email technical circles, I believe it does not have clear, consistent, and precise meaning.  So it needs to b

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 11/15/2024 10:55 AM, Alessandro Vesely wrote: Just a side note... On 13/11/2024 21:14, Dave Crocker wrote: While 'indirect' has well-established context in many email technical circles, I believe it does not have clear, consistent, and precise meaning.  So it needs to be defined here, with

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

Just a side note... On 13/11/2024 21:14, Dave Crocker wrote: 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 pro

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

Hi... On 11/7/2024 6:42 AM, Murray S. Kucherawy wrote: 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/ Commenting on that draft: Attribution of email is made difficult by the exact properties that

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 11/9/2024 9:28 AM, Jim Fenton wrote: How about adding, "Scalability is also an important design consideration that the WG will take into account."? Adding something like this to a charter implies that it is not typical for IETF protocols to be able to scale. And since scaling is pretty

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Fri 08/Nov/2024 21:29:18 +0100 Richard Clayton wrote: In message <71800411-665a-41c8-acda-2060b2c08...@tana.it>, Alessandro Vesely writes [some stuff] seem difficult to implement into a filter, perhaps depending on which API different MTAs provide. Libraries cannot do that. I was not sug

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 9 Nov 2024, at 17:07, Jim Fenton wrote: On 9 Nov 2024, at 13:16, Pete Resnick wrote: On 9 Nov 2024, at 8:38, Jim Fenton wrote: suggest that the charter acknowledge that scalability is important and stop there. Well, I would also like something that is clear that running code is favored

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 9 Nov 2024, at 17:25, Pete Resnick wrote: > On 9 Nov 2024, at 17:07, Jim Fenton wrote: > >> On 9 Nov 2024, at 13:16, Pete Resnick wrote: >> >>> On 9 Nov 2024, at 8:38, Jim Fenton wrote: >>> suggest that the charter acknowledge that scalability is important and stop there. >>> >>> W

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <1810e35c-f268-4040-af09-073cccbae...@bluepopcorn.net>, Jim Fenton writes Since I think we have a duty not to heat up the planet any more than absolutely necessary, and since designs with large numbers of crypto operations (to achieve limi

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 9 Nov 2024, at 13:16, Pete Resnick wrote: > On 9 Nov 2024, at 8:38, Jim Fenton wrote: > >> Email, as a service, has to serve both large providers and small. It’s >> important that the charter consider the needs of small providers as well as >> the large ones. This is a theoretical concern at

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 9 Nov 2024, at 8:38, Jim Fenton wrote: Email, as a service, has to serve both large providers and small. It’s important that the charter consider the needs of small providers as well as the large ones. This is a theoretical concern at this point, and I hope we don’t end up in a situation wh

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 8 Nov 2024, at 23:20, Pete Resnick wrote: On 8 Nov 2024, at 16:13, Murray S. Kucherawy wrote: If the goal is to favor running code over mere pontification, I think that's a solid proposal... That it certainly true. But I think we do want code that is not just running, but is also usable

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 8 Nov 2024, at 16:13, Murray S. Kucherawy wrote: If the goal is to favor running code over mere pontification, I think that's a solid proposal... That it certainly true. But I think we do want code that is not just running, but is also usable at scale. Maybe that's what's not clear: It do

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <71800411-665a-41c8-acda-2060b2c08...@tana.it>, Alessandro Vesely writes >Some features, such as breaking multiple recipients into multiple messages (as >if they were destined to multiple domains) your MTA will already have a setting fo

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Fri 08/Nov/2024 14:28:53 +0100 Richard Clayton wrote: In message , Murray S. Kucherawy writes A small operator or individual with a good idea that lacks the resources to test at scale shouldn't be excluded unnecessarily. Are the large operators reasonably willing to test promisin

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Fri, Nov 8, 2024 at 1:33 PM Richard Clayton wrote: > Since a great deal of the functionality of DKIM2 will in practice be > placed into standard libraries, providing running code for such a > library will make it possible for large operators to deploy experimental > ideas for particular domain

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Murray S. Kucherawy writes >A small operator or individual with a good idea that lacks the >resources to test at scale shouldn't be excluded unnecessarily.  >Are the large operators reasonably willing to test promising idea

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

Sorry, typo: On Fri, Nov 8, 2024 at 12:14 PM Murray S. Kucherawy wrote: > On Fri, Nov 8, 2024 at 11:41 AM Pete Resnick 40episteme@dmarc.ietf.org> wrote: > >> Yeah, I helped in crafting that sentence and Eliot's view is what we were >> going for: It's not that you need to be a large provider

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Fri, Nov 8, 2024 at 11:41 AM Pete Resnick wrote: > Yeah, I helped in crafting that sentence and Eliot's view is what we were > going for: It's not that you need to be a large provider, but the > expectation is that if you've got implementation and can show that it > interoperates at reasonable

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 8 Nov 2024, at 6:53, Eliot Lear wrote: Hi! On 07.11.2024 22:10, Jim Fenton wrote: On 7 Nov 2024, at 18:21, Mark E. Mallett wrote: To gain widespread adoption, it is expected that design proposals will be tested during the development of specifications. The working group will favor

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Fri, Nov 8, 2024 at 11:14 AM Alessandro Vesely wrote: > On Thu 07/Nov/2024 22:24:51 +0100 Steffen Nurpmeso wrote: > > Alessandro Vesely wrote in > > > > |considering easier alternatives that can make ARC more usable for > trusted > > |forwarding and mailing lists, perhaps on a different li

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Thu 07/Nov/2024 22:24:51 +0100 Steffen Nurpmeso wrote: Alessandro Vesely wrote in |considering easier alternatives that can make ARC more usable for trusted |forwarding and mailing lists, perhaps on a different list. You cannot warp trust around the corner. You can have users confirm

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

Hi! On 07.11.2024 22:10, Jim Fenton wrote: On 7 Nov 2024, at 18:21, Mark E. Mallett wrote: 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 dism

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 11/6/24 4:26 PM, Bron Gondwana wrote: I think now is an ideal time to re-start this work at the IETF. The design is still evolving and there's plenty of space for an IETF working group to improve it further, yet it's also had enough design work put in by people with operational experience

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

Hi All, Fully support this, and looking forward to seeing it through to a working implementation at Fastmail, and as maintainer of the Mail::DKIM Perl module. On Thu, 7 Nov 2024, at 11:26 AM, Bron Gondwana wrote: > Hi All, > > I prepared presentations about DKIM2 for two places at IETF121 - ALL

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

Alessandro Vesely wrote in <319a066f-5719-4569-8e5e-3d46cef5b...@tana.it>: |On Thu 07/Nov/2024 01:26:46 +0100 Bron Gondwana wrote: |> I think now is an ideal time to re-start this work at the IETF.  \ |> The design is |> still evolving and there's plenty of space for an IETF working group \

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

Am 07.11.24 um 01:26 schrieb Bron Gondwana: We have a draft charter here: https://notes.ietf.org/YGynIPpYS7yqg5G7ZeSQeA Hello all, I also support the proposed work. My focus is not the design in a first place. I trust the people with much more expertise here ... I favor the operational view

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 7 Nov 2024, at 18:21, Mark E. Mallett wrote: > Commenting from the peanut gallery: > > I've looked at some of the things that have been sent out in the > recent past and have been quite interested. I'll follow along and > participate to some degree once I know where.. But: > > On Thu, Nov 07, 2

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

I also strongly support this initiative. I really like what I've seen of the work on this so far; it's clear a lot of thought has been put into this design, and I want to express my appreciation to Wei, Bron, and Richard for their efforts on this - as well as anyone else who's contributed. My inte

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

As a member of the sending community I am very excited about the work Bron, Richard and Co. have already done and have joined here to help continue the work. This proposal will help with dkim-reply and if done correctly could eliminate the need for ARC and possibly even SPF. We need a new way to

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Thu 07/Nov/2024 01:26:46 +0100 Bron Gondwana wrote: I think now is an ideal time to re-start this work at the IETF.  The design is still evolving and there's plenty of space for an IETF working group to improve it further, yet it's also had enough design work put in by people with operatio

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

, Alex Date: Thursday, November 7, 2024 at 11:13 AM To: Bron Gondwana , ietf-dkim@ietf.org Cc: Wei Chuang , Richard Clayton Subject: [Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2 The motivations have been stated, and I think most folks agree with them. It feels like the

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

Commenting from the peanut gallery: I've looked at some of the things that have been sent out in the recent past and have been quite interested. I'll follow along and participate to some degree once I know where.. But: On Thu, Nov 07, 2024 at 03:55:18PM +, Bron Gondwana wrote: > > To gain w

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

The motivations have been stated, and I think most folks agree with them. It feels like the proposed features should be easily adoptable by a majority of participants in the ecosystem. Looks to be a good way forward, and an improvement for parties involved. -- Alex Brotman Sr. Engineer, Anti-A

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Thu, 7 Nov 2024, Richard Clayton wrote: One nit, that can be addressed in one of the outcomes: DKIM2 best DNS practices. ... elliptic curve keys are considerably smaller than RSA keys ... I have heard people argue that we should deprecate RSA keys, but that would mean that you could not use

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

I think there are operational documents on key rotation and best practices. I think M3AAWG has such documents, however, my point is that this group should strive to design a protocol that makes life easier for all of us. IETF security goals sometimes fails because operationally it is very heavy.

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

: PROPOSAL: reopen this working group and work on DKIM2 On Thu, Nov 7, 2024 at 4:26 PM Franck Martin mailto:fmar...@linkedin.com>> wrote: A last nit, many standardized on opendkim, because of interoperability. There were too many weird things happening between different implementations of

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On 7 Nov 2024, at 16:26, Franck Martin wrote: This charter looks very good, but.. I think it is missing to address explicitly the following pain points: key rotation and cypher upgrades. Cypher upgrades seems like a reasonable thing to mention in the charter, even though I'm pretty sure that

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Thu, Nov 7, 2024 at 4:26 PM Franck Martin wrote: > 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,

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

good work. From: Bron Gondwana Date: Thursday, November 7, 2024 at 07:57 To: Murray S. Kucherawy , Bron Gondwana Cc: ietf-dkim@ietf.org , Wei Chuang , Richard Clayton Subject: [Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2 The proposed charter text has been workshopped

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Thu, Nov 7, 2024 at 9:58 AM Bron Gondwana wrote: > > 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): [...] > As

[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 p

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

On Thu, Nov 7, 2024 at 12:27 AM Bron Gondwana 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 peo

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

I see numerous advantages in many of the proposed changes, and I’m eager to continue working towards building a consensus around this proposal. In my day job, we’ve had to allocate significant engineering resources to mitigate DKIM replay abuse affecting our domains. We’d much prefer to channel

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

As the former chair of the dissolved working group, I support this work. Unlike the previous group, this has much more community buy in and folks who are willing and able to contribute to the effort. This work also focuses on overall improvements to the protocol in a way that reflects how modern

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

I'm looking forward to engage in consense finding discussions. At my dayjob at GMX/Web.de/Mail.com I already reserved engineering time for the coming months to work on inter-op testing of this. / Tobias Herkula From: Bron Gondwana Sent: 07 November 202

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

I also wanted to voice strong support for this initiative. One of the key goals of this work is to authenticate messages that go through mailing lists that may modify the messages e.g. adding subject prefixes or footers to the body. The proposal on

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <8fbb182e-cfed-422e-a2d3-a1a2ebf63...@app.fastmail.com>, Bron Gondwana writes >I prepared presentations about DKIM2 for two places at IETF121 - >ALLDISPATCH and MAILMAINT.  Slides are here: > >ALLDISPATCH: > > https://dat