On Oct 23, 2008, at 11:49 AM, Murray S. Kucherawy wrote:
Douglas Otis wrote:
The ADSP draft inhibits an assurance regarding _what_ the signing
domain authenticated! The Author Signature definition limits a
signing-domain's associated "on-behalf-of" identifier to being an
email address within the From header field or to being _blank_.
As a result, any intra-domain abuse can not be safely identified.
One would be mistaken to assume the From email-address is always
what a signing domain authenticates. No other assumption would be
available without incurring an impractical second signature that is
likely ignored anyway. Should one care about the damage created by
an incorrect assumption regarding authentication, even when the
assumption is signed by the border MTA? Perhaps this could be call
the Assumed-Authentication-Results header. : )
-Doug
Doug,
I'm pretty sure you're talking about the reliability/assertions of
ADSP or even DKIM. That's orthogonal to what we're discussing here
on mail-vet-discuss. This draft is about moving the evaluation
results from an MTA to MUAs in a consistent and reliable manner.
That the evaluations themselves could conceivably be flawed or
subverted is already discussed in Security Considerations for this
draft and is not within the scope of this document.
I responded to a different message on mail-vet and dkim. Here is the
portion that attempts to explain the concern:
A security mechanism should not recklessly abuse the term
Authentication. The term Authentication is _dangerously_ misleading
for most methods logged by this header. The term "Authentication"
should be replaced by a neutral term "method" within draft where
possible. It would not be too misleading to use the terms
"Authentication or Authorization" instead of just "Authentication"
within a few sentences. A header label "Source-Results" would be
less deceptive in respect to the nature of the results obtained. The
term Authentication is being misused more than 60 times through out
this draft (ignoring the title and header labels). Admittedly the
word "authorized" is buried in the definition of some results, but
this term will _never_ be evident to the user. Do you see the danger
using the header label "Authentication-Results:"? The draft's
introductory statement does not help much either:
"At the time of publication of this draft, [AUTH], [DKIM],
[DOMAINKEYS], [SENDERID] and [SPF] are the published e-mail
authentication methods in common use."
Authentication methods? Really?
It is _dangerous_ and _misleading_ to suggest that an SMTP client
_authorization_ method results in the "authentication" of the PRA,
MAILFROM, the valid origination of the message as stated in this
draft. An _unauthorized_ SMTP client MAY be an indication of the
invalid use of a MAILFROM or PRA, however an authorized SMTP client
must not be assumed to indicate the valid use of an email-address, as
suggested by the overused term "Authentication" through out this
draft. Describing an authorization method as being an authentication
method results in a dangerous misrepresentation of the results
produced for most of the methods currently defined, even for DKIM-ADSP
at this time.
Get rid of the sales hype describing everything as "authentication".
Security is no time for muddled or misused terminology. There is no
reason to mislead recipients any more than they already are.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html