On Sep 22, 2006, at 4:12 PM, Michael Thomas wrote:
Douglas Otis wrote:
On Sep 22, 2006, at 1:56 PM, Michael Thomas wrote:
The intention here is not to validate each point of the positive
and negative commentary, but to bring the issues to the fore so
that the entire scenario and requirements it generates can be
understood in the context of what has gone on with the list. If
I have transcribed the negative commentary incorrectly, I'm open
to fixing that, but striking each point fundamentally misses the
point of why it's in the draft.
This transcribed commentary is one-sided and lacking a basis.
Whether supported by a few on list at the time, it is still wrong
and does not belong in the requirements document.
It's not one sided -- it's my attempt to summarize what a lot of
voices on the list have said. As for lacking a basis or "wrong",
that's true if the only one who gets a say as to what constitutes
"basis" or "right" is you. Aside from being unfair, it's not the
point of the draft either: the draft's intent is to summarize what
people want, what people don't want, and whether the wants are
feasible or needed now so that we can have a basis to decide what
the subset of wants (requirements) that we will demand of the
protocol.
It is clear from other comments on the list, you oppose a concept of
designation rather than delegation. The basis for the negative
commentary presumes DNS delegation is less risky or represents
current practices. Several on this list, including Stephen,
expressed concerns regarding DNS delegation with the exchange or
possession of private keys by third-parties. This continues to be
ignored in this requirements draft. DKIM's use of selectors, private
keys, key specific settings, etcetera, represent significant and new
complexities with a DNS delegation technique. I see no purpose in
adding the negative commentary other than to introduce impediments to
fuller discussions or to summarily dismiss the designation technique
altogether.
In either situation of designation or delegation, the provider must
be trustworthy. As possible with the 'i=' semantics in the signature
header denoting when the email-address has not been validated, the
same semantics are equally possible with any reasonable designation
technique, but where the email-address domain owner controls the
assertion. When the goal is to ensure a message is signed by a
designated entity for acceptance, assurances of email-address
validity may be secondary. In the current email infrastructure,
assurances of an email-address being valid may be the exception.
Even so, a designation technique still allows validation techniques
that are confirmed with a designation assertion.
Does anyone think that:
<base32(sha(signing-domain))>._dkim-hdr-x.<email-domain> TXT
"d=signing-domain; f=A;"
This represents a single DNS lookup of a small RR. Does any think
this is overly complex and does not scale?
While clearly some may find nirvana having all originating domains
match the signing domain, this is not practical.
There is value in having the signing-domain be concurrent with that
of the domain administrating the actual transmission of the message.
Here DKIM would ensure abuse feedback finds the appropriate party.
A simple technique to associate the signing domain with other email-
addresses within the message allows DKIM to block forged DSNs for
example. It would also allow the email-address domain owner to
autonomously decide whether they wish to designate their provider,
and to indicate specifically what role the provider plays. DNS
delegation removes control from the email-address domain owner, while
at the same time requires the email-address domain owner to answer
for signed content they may have never seen!
The negative commentary does not belong in the requirements draft.
It is wrong and biased.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
