On Jun 16, 2009, at 2:35 PM, Michael Thomas wrote:
There are a few points that seem to be lost in all of this:
1) People saying that d= is THE IDENTIFIER are overloading the
value: d= a routing label to a particular DNS subtree. Whether it
has anything to do with THE IDENTIFIER is purely coincidental. The
assumption that these two functions are identical is bogus. i= was
supposed to be this stable value detached from the mechanical DNS
routing function.
2) assessors are going to use what they find useful regardless of
whether we hurry this draft out any faster or with any less review.
3) What's "useful" to assessors, d=, i=, or even x= is out of scope
for the DKIM wg. The level of interoperability being pursued here
much higher level than anything we ever signed up for. We shouldn't
force normative changes on implementations for functions outside of
the scope of this working group.
4) #3 is doubly true since we don't even have any feedback, or an
actual problem being reported in the field. when I asked about this
at the SF meeting, I got a lot of bluster about "not revisiting
first principles".
In conclusion, changing a spec absent actual problems in the field
and to solve problems that are outside of charter seems dubious and
dangerous. Doing so as an emergency must-fix update is even moreso:
it tells the world that there's something dreadfully wrong with DKIM
when that's far from the case.
Agreed.
A while ago, I wrote a specification defining a device interface over
a new physical layer that encompassed a well established command set.
A large drive company wanted the specification "simplified" to meet
their specific needs. Changing the specification was accomplished
largely through intimation. Ironically, the 900 lb company then found
their product was no longer supported by a 900 lb OS vendor as it had
initially been, and neither were happy. What had been removed was in
fact being used. Had anyone within management of the drive company
understood the role played by the elements being removed, they would
have discovered a transparent bridge within the OS, whereas the
"simplified" specification (which they wanted as their OEM manual)
required product specific fix-ups.
One might expect the motivation for changing DKIM is to establish
parity with path registration. In doing so, header specific
annotation with its protection from intra-domain spoofing is reduced.
Mitigation of replay abuse due to a small number of problematic
accounts also becomes difficult when the i= value is depreciated as
being just an optional second choice. The i= value should be the
first choice. The d= value is only to be used when the i= is not
present, as _defined_ by RFC 4871.
Assessments clearly are unable to cope with the unlimited intra-domain
identifiers allowed by i= values. However, most legitimate domains
are fairly well managed where there is a small percentage of
problematic accounts. An assessment process will need to establish an
upper bound for the number of such problematic identifiers per domain,
and either base their response upon the problematic intra-domain
identifiers, or that of the entire domain. Using a one way hash for
the i= value below the d= value allows a simple and deterministic
query for either an intra-domain identifiers or a global domain
responses. I would be happy to create a draft to standardize this
exchange.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html