-----Original Message-----
From: Douglas Otis [mailto:dotis(_at_)mail-abuse(_dot_)org]
Sent: Tuesday, September 28, 2010 7:01 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/28/10 3:27 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.
The TPA-Label draft offers additional ADSP assertions having semantics
intended to support _existing_ mailing-list and third-party practices.
The DKIM charter states the following:
,---
Consider issues related to mailing lists, beyond what is
already documented. ...
'---
I believe the intent of that item is to document current MLM/DKIM issues vis a
vis already-published documents, as is done in the draft that is currently a WG
item. Extending ADSP or creating new protocols doesn't seem to fit within that
goal.
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.
Sorry, should have said DKIM/ADSP deliverability, which is based upon
DKIM Author Domain Signatures. The TPA-Label draft offers alternative
ADSP assertions that indicate the possible availability of domain
specific exceptions. When exceptions are not found, non-compliant
messages are to be rejected, as opposed to being discarded or scored in
some fashion.
I'm confused. You say TPA allows fallback to other adopted verification
methods, but you also say it refers specifically to DKIM/ADSP deliverability.
I'm not clear on how both can be simultaneously true.
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?
See:
http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06#section-12.4
The SMTP EHLO or HELO hostname must resolve the IP address of the SMTP
client. Reverse DNS is not used.
I think that's a marginal improvement. Even if the HELO/EHLO parameter can be
resolved to the client IP address, that doesn't tell you anything about the
client other than it has control over some portion of the DNS.
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.
Requiring additional header field compliance better ensures different
mail streams remain recognizable by recipients. Many MUAs already
display Sender,
Which ones? None that I've ever used do.
and many who subscribe to mailing-lists already sort
using List-IDs. Whether or not recipients see the required header
field, their requirement helps isolate authorizations to specific mail
streams, such as messages emitted by the authorized domain's
mailing-list services. The TPA-Label response includes authentication
requirements intended to exclude miscreants. The general premise is
exceptional authorization is only given to trustworthy services.
Again, I'm not seeing the utility here. If A can say "You can trust that mail
apparently from us and signed by B is authorized by us as long as it bears a
Sender: header field containing B", then an intruder compromising B need only
meet that requirement to be able to send mail as A and have verifiers
improperly trust it. That you're catering to MUA display or sorting options
only makes that worse in my view. In any case, it's a tiny hurdle to overcome
once a penetration has occurred. Thus, there seems little gain here over
simply authorizing B to sign for A regardless of message structure.
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev