-----Original Message-----
From: Douglas Otis [mailto:dotis(_at_)mail-abuse(_dot_)org]
Sent: Tuesday, September 28, 2010 3:02 PM
To: Murray S. Kucherawy
Cc: dkim-dev(_at_)mipassoc(_dot_)org; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Authorizing List Domains
On 9/27/10 9:47 PM, Murray S. Kucherawy wrote:
On Monday, September 27, 2010 4:19 PM, Douglas Otis wrote:
TPA-Label involves ADSP being discussed on the dkim list.
Unless you're talking about revising ADSP (which it seems you are specifically
not doing since TPA is meant to cover other technologies as well; plus, ADSP
wasn't in your list), we're talking about something new that is not in the
current DKIM WG Charter.
That seems antithetical to the idea that this is all experimental
work, explicitly not on the standards track.
Some have expressed strong desires to improve DKIM deliverability by
allowing fallback to other adopted verification methods. TPA-Label
permits such fallback without also requiring the same domain be used by
alternative methods.
The first sentence there seems contradictory to me; if you're falling back to
other methods, we're no longer talking about mere DKIM deliverability.
DKIM is unable to unilaterally authorize third-party services which
impedes use of restrictive acceptance criteria.
DKIM specifically allows a domain to give a third party signing authority by
putting into the DNS a public key matching a private key that is in possession
of that authorized third party. Unless there's an assertion being made that
this mechanism creates a hardship, I'm still not clear why that's been
dismissed as a possibility.
Since any client can say anything it wants for an EHLO parameter, why
should it be considered a type of authentication?
The SMTP client identified by the EHLO might resolve the IP address
used in the exchange. While such resolution is not required by SMTP
protocol, it might offer an opportunistic means to authenticate the
administering domain as a fallback method.
The DNSOP working group has repeatedly advised against use of reverse DNS as a
mechanism for client authentication. Do we claim to have expertise they are
lacking?
For that matter, one could invent a scheme that mandates any piece of data must
match any other piece of data, both of which are potentially (perhaps even
often) under the control of a miscreant. I'm not sure I see how this is useful.
Moreover, identification of a client as legitimate or otherwise based on
HELO/EHLO data has proven problematic if only because of common configuration
errors. Enforcing something along these lines will likely create more
operational problems than it solves.
These header fields must match against TPA-Label specified domains. The
contained domains ensure the effectiveness of message sorting or header
display in allowing recipients a means to differentiate email sources
that might also contain the From header used by ADSP. The source of
these header fields must also correspond with specified domain and
authentication/verification methods.
ADSP makes a binding between the "d=" and the domain in the From: field, the
most visible of them all, and we've seen extremely narrow use of this, much
less success. I have doubts that expanding that logic to other less common or
less visible fields will see more adoption or success.
I think if you're going to say a particular domain is authorized to sign your
mail and verifiers should consider such mail "good", then you've already
granted that domain the ability to pass your policies through at least one
vector. Constraining that domain to pass your policies only one particular way
doesn't gain you anything: Either the domain is not compromised in which case
everything's fine anyway, or it does get compromised in which case the intruder
can simply generate malicious mail within the constraints of your policy, and
you're burned regardless of what policy you post.
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev