David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx> writes: >> From: Michael Thomas <thomasm@xxxxxxxxx> ... >> At the MASS/DKIM BOF we are being required to produce such a thing as a >> prerequisite to even getting chartered as a working group. > >A more pertinent request at that stage might be, "Please clarify the security >requirements for this protocol." I believe that the "threat analysis" that the proposal authors created in the days before the BOF did the above, documenting how DKIM could be attacked, what it depended on or assumed, etc. IMHO however, that's quite different from what ended up being the sticking point at the BOF, which you see as a paraphase of the above: >IOW, what is the protocol supposed to >enforce or protect, under the assumption that it will be used in the Internet >environment with the "fairly well understood threat model" described above? To me, _that_ question sounds more like "what does this accomplish?", which belongs in a use cases doc, or maybe flipped around and placed in a requirements doc. In the case of DKIM, that can be phrased as "How does this address items in the threat analysis for SMTP and the Internet email architecture?" From the people I've talked to and what happened at the BOF, it seems that at least some of the requests that came across as being for "a threat analysis" were intended for this latter meaning. IMHO, the phrase "threat analysis for <X>" should refer to the analysis of attacks, dependencies, and assumptions of <X> and _not_ include the list of threats to other protocols that <X> addresses. Those aren't threats to <X>, they're *opportunities* *for* <X>! But maybe the people who live and breath security analyses find that the broader meaning is more useful. If so, *someone* should document that fact and security people should actively refer to that document when requesting such analyses for the benefit of those of us who aren't versed in the jargon. That may be a good idea even if security people prefer the narrower meaning, given the incredibly vague definition in the FYI cited by Bruce Lilly. Anyway, a miscommunication occured that resulted in time wasted. Not the time spent on the DKIM threat analysis, as that'll be needed later, but rather the time of _many_ people spent at a BOF that was less productive than it could have been. The point now isn't to blame anyone but rather to avoid this communication failure in the future. How can we do that? Philip Guenther "Just an email guy" _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf