Folks, I'm trying to do an audit of the issues folks have raised, and aggregate them.
Along the way, I'm finding a few items that are quite specific, so I'm trying to deal with them separately. From Jim's note, a couple of items don't fit well into the aggregation exercise, so... > 5. Security properties: DKIM was designed to provide a modest level of > security limited by the security properties of DNS. This was considered > acceptable because it's comparable to the level of security afforded > message routing (since MX records could be spoofed). Other uses of DKIM > need to be examined carefully to make sure that we do not depend on an > insufficiently secure key infrastructure. While use of DNSSEC mitigates > this, I'm concerned about whether it will really be used everywhere needed. There are two lines of answer to this: 1. Each new use of the core will need to decide whether the facilities that are provided by the core are sufficient to that use's needs, including any implied or actual security model. 2. In deciding how to do the documentation split, there is, in fact, some challenge in deciding how "general" to make the core specification. The circulated table of contents for DOSETA cites an authentication template. I had originally hoped to make it fully general, to essentially any sort of (structured) object. That proved unwieldy, so it is limited to objects with a basic header/content form. Happily, that happens to cover quite a lot of ground. Still, it's a limitation. The point I'm making is that the proposed split is not intended as an exercise in "interesting" security design but merely one of extracting the core of DKIM and making it more easily accessible to other services that find it a good match. > 6. Redundancy: Section 10.1 of the iSchedule draft requires the use of > TLS for all transactions. Why is DKIM then also needed (if the > certificate verification happens in both directions, of course)? Why > are two very different mechanisms in use? The proposal is not based on the needs of iSchedule. (In fact, I hadn't know about that effort; I also note how old and apparently inactive that effort is.) iSchedule merely happens to provide an interest example of a candidate RE-user of DKIM's core. As for any other details involving iSchedule, they have nothing to do with this effort or the DKIM working group. > 7. Openness and Timeliness: Barry has apologized for not announcing this > a month ago, but I sense that this has been going on in a private design > team longer than that. BCP 9 section 1.2 talks to openness and > timeliness; this fails on both accounts. This effort began as a personal bit of research. I've been hearing increasing rumblings about extended uses for the technology. In fact it was clear from the start that the core had more general utility; it was also clear that we needed to focus on one application, so as to not lose focus. The first file I created on the topic seems to have been November 10th. The first time I showed it to anyone else was around December 8th. However, none of this really matters. What matters is that IETF culture and rules require that decisions be made by the working group, and that's what is happening right here, right now. And the flow of the postings make it pretty clear that if there were a conspiracy-like effort underway, it wasn't managed very well... In fact, the IETF is actually structured with the assumption that everyone is biased, that they have an agenda. This is an advocacy and adversarial environment. So, everyone must surface the details of the work. That is, what matters is that technical issues must be made public and must be resolved publicly. What happens prior to that does not matter much. Rough consensus means that enough people like an idea or a specification, no matter its source. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
