There is an existing draft of a problem statement, so there's at least a starting point to consider. I think discussion about what's needed is probably more useful relative to a specific draft than in the abstract:
https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/ Scott K On February 2, 2023 11:26:36 PM UTC, Michael Thomas <m...@mtcc.com> wrote: > >On 2/2/23 3:18 PM, Tim Wicinski wrote: >> the problem statement should just bang out the problems in all their ugly >> glory. >> it should not attempt to suggest solutions, as that would be up to the >> working group >> to hammer out. >> >> (this is my opinion and of course am probably totally off base) > >I guess my concern is more along the lines of what solutions *aren't*. There >are a bunch of drafts trying to tie the envelope to the email and I think >there needs to be a meta discussion of whether that is a good idea or not in >general. Frankly that seems like an email architecture question not just a >DKIM question. It would be nice to know if there is precedent for that in the >larger community and what the implications are. Fwiw, I don't really consider >the DMARC "alignment" as tickling the larger question because all it is doing >is reporting on it, but a case could certainly be made that it is. > >Mike > >> >> >> On Thu, Feb 2, 2023 at 5:32 PM Michael Thomas <m...@mtcc.com> wrote: >> >> >> On 2/2/23 2:16 PM, Tim Wicinski wrote: >>> >>> >>> On Thu, Feb 2, 2023 at 5:07 PM Michael Thomas <m...@mtcc.com> wrote: >>> >>> >>> So here is what sticks in my craw. I think I brought up the >>> problem >>> statement, but maybe somebody else did before me. It's easy >>> to say "here >>> is the problem, fix it!" without any context to what any >>> proposed fixes >>> might break. It would be really bad imo to slap out a minimal >>> problem >>> statement and then proceed to solutions without any analysis >>> of what any >>> solution space should and should not do at a protocol level. >>> I guess >>> that's a little bit more requirement-y, but I'm not exactly >>> sure what >>> process-wise I'm asking for. DKIM is extremely widely >>> deployed so we >>> need to be really careful about not breaking existing >>> practices or doing >>> unnatural acts that have implications to the wider email >>> community. >>> >>> >>> My feeling part of the problem statement will be to document >>> various solutions >>> and how testing should be done and what to look for (breaking >>> existing practice would >>> be key). >>> >>> It may be that one solution is protocol rev which works outside >>> of current dkim. >>> We wrestled with this in the early days of DPRIVE - adding >>> additional encryption onto >>> DNS was viewed in a similar manner. >>> >>> >> I don't know if there is a formal IETF definitely of what >> constitutes a problem statement but it's easy to imagine a problem >> statement that... just states the problem. I don't think we have >> discussed what should actually be in scope for this problem >> statement. I guess we could suss that out before there are chairs, >> but obviously we'd need them to make consensus calls. >> >> Mike >> _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
