On March 27, 2023 3:10:40 PM UTC, Laura Atkins <la...@wordtothewise.com> wrote: > > >> On 26 Mar 2023, at 11:13, Murray S. Kucherawy <superu...@gmail.com> wrote: >> >> On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas <m...@mtcc.com >> <mailto:m...@mtcc.com>> wrote: >>> On 3/24/23 6:19 PM, Barry Leiba wrote: >>> > I don't agree with the premise. I think what was tried and didn't >>> > work should be documented in the result that the working group comes >>> > out with, but not in the problem statement. >>> >>> There isn't a place in the charter/milestones for that. >> >> The charter identifies these possible outputs in some combination: >> >> (1) a clear problem statement; >> >> (2) one or more protocol update document(s); >> >> (3) a statement of some kind that the WG determined no feasible protocol >> solution exists (and, one would hope, how it reached this conclusion); >> >> (4) an update to current DKIM operational advice with respect to the stated >> problem. >> >> The only constraint in the charter is that (2) and (3) are mutually >> exclusive. > >Agreed with all of this. > >> I believe that a history of what techniques were previously tried and failed >> could arguably go into any of them. The charter is neither prescriptive or >> proscriptive on this point. > > >It seems to me a history of what did work / didn’t will go into document 4 or >the reasoning for document 3. My current preference is for the discussion to >not be in the problem statement. My reasoning is that there will be discussion >about what didn’t work and why it didn’t work. I expect that there will be >quite a bit of back and forth to capture the details of why something didn’t >work - including the adaptations that the attackers made to the changes. This, >to my mind, is the job of the working group: to look at the current status, >discuss where the holes are and if they are protocol holes or if they are best >practice / implementation holes. > >On a more practical point, we have a month to finalize the problem statement. >No one has proposed language to include in the problem statement about what >has worked and what hasn’t worked. Given the current state of the group, I >simply don’t think we have the time to put this into the problem statement and >get it out in time. > >I do think we have the time and space to discuss techniques after the problem >statement is done and include it in one of the WG output documents. > So far, unless I was napping when it happened, we don't have a working group draft of the problem statement.
Personally, I'm waiting for draft-chuang-dkim-replay-problem-02 before investing any more time on the problem statement. I think it would make sense for the group to do a quick assessment of it, when it is available and see if we want to adopt it as a working group draft (I strongly suspect we do). Once that's done, I think there will be a solid basis for progress towards the milestone. In the meantime, if someone wants to write up a section on what's been tried, I don't think it's on the critical path for the milestone until there's agreement to add it to the document. It certainly doesn't delay anything now while we're waiting for the -02 of the problem statement. If the text can be developed in parallel, it might not affect the schedule significantly. Myself, if we can, I think we should (I will volunteer to review and provide feedback on this but not to write it - I don't have the time). Scott K _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
