On 1/3/23 8:59 AM, Todd Herr wrote:
On Mon, Jan 2, 2023 at 3:04 PM Evan Burke <evan.s.bu...@gmail.com> wrote:
On Sat, Dec 31, 2022 at 10:44 PM Wei Chuang
<weihaw=40google....@dmarc.ietf.org> wrote:
> I'm worried about duplicating work unnecessarily as the M3AAWG
has an email authentication BCP. If the WG to-be indeed does want
to generate the BCP, perhaps the M3AAWG document can be the basis
for an IETF document assuming M3AAWG is okay with that, or the WG
can partner with M3AAWG to produce a common document. I think
both are possible as there's a fair amount of people overlapping
between the IETF and M3AAWG, and I know that M3AAWG
organizationally wants to help here.
I believe there's a revision underway for the general M3AAWG auth
BCP doc, which will include a handful of sender-focused
recommendations for reducing the viability of replay attacks.
There is also a DKIM replay specific M3 BCP doc in progress with
more in-depth recommendations.
Evan is correct on this point; there is a revision underway for the
general M3AAWG auth BCP doc, for some values of "underway", anyway.
I'm the person who's taken on the responsibility for authoring said
revisions, but I've been waiting for the M3AAWG DKIM Replay work to
produce something tangible to ensure that what I write doesn't
conflict with that work.
Yet another reason why I'm skeptical. If there were a viable protocol
solution to this, why hasn't M3AAWG found it? Why re-spin up a working
group with a what appears to be a greenfield solution space if an active
industry working group hasn't chimed in? If there were some viable
protocol solution, I would expect they would at least put it forward.
Working groups are infinitely more productive if there is some
collective agreement about the general parameters of a solution, even if
the particulars need to be vetted. The couple of solutions I've seen
thus far are either trivially breakable (= striping signatures at
MDA's), or frightening to contemplate what they'd break (= tying
envelope to message). That doesn't give me the warm fuzzies about any
protocol level solution.
Also: if they are indeed working on a BCP, it would be far better to use
that as input rather than reinventing wheels.
Mike
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
