Eric Allman wrote: > Dave, I'm not understanding how the algorithm can work if you omit step > 2 from section 4.2.2. > > Suppose that example.com wants to assert to the world that it signs all > messages. It will create an ADSP record for example.com with the > appropriate assertion. Without step 2, all an attacker has to do is to > craft a message purported to be from "[EMAIL PROTECTED]"
Eric, Actually from your note, it looks to me that you understand just fine. It looks as if the question is covering a single-name vs. a sub-tree. Your note mostly takes sub-tree as an implicit given, but then states it explicitly at the end. The attack that you describe requires using some name other than the one that is listed. The single, specific name that is listed is, indeed, "protected". > If that's what you mean when you say "that presumes the goal of > protecting an entire sub-tree" then I'm all for protecting the entire > sub-tree. Anything less looks to me like it severely weakens the entire > point of ADSP. (Aside: Folks keep correcting my own use of the word "protect" for DKIM or ADSP and given the delicate balancing act that ADSP must walk, I think their concern is quite reasonable. So I'm trying to switch over to say "cover"...) You echo the word "goal". That certainly seems like the right starting point. Does the working group assert the goal of covering entire sub-trees? Note that this isn't in the working group charter, the requirements statement, or even explicitly stated in the specification. That does not make the goal inappropriate, but it does mean that it needs to be stated and confirmed explicitly. (And certainly the specification needs to state this explicitly and clearly.) But frankly that's the easy part. Because we then we have the small question of what are the technical requirements and details, for covering a sub-tree adequately, within the DNS, when using an underscore sub-naming scheme? Given that the DNS is not designed to permit this conveniently and, in fact, does not seem to me to be able to do it at all, we certainly need a complete and coherent technical description of how ADSP accomplishes complete coverage of a sub-tree. This would describe the approach being taken for covering a sub-tree, and the component mechanisms being used to achieve it -- Step 2 is but one of those components. It would also demonstrate what kind of attacks it protects against. I am not aware of any previous technology providing such sub-tree functionality, and so this ought to be subject to careful review by the DNS and Security folks. At that, I fear it will nonetheless warrant a status of "experimental". So in terms of a "goal" I'm probably in agreement that it would be dandy to do. But I think that my desiring that goal is pretty much irrelevant. The problem is that I believe there is no technical means of covering a subtree completely, except by case-analysis, which isn't covering a tree at all. I believe the Step 2 query only makes sense for ADSP in the context of covering an entire sub-tree, but that ADSP does not describe the larger framework into which Step 2 fits, for accomplishing that goal. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
