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