[dkim-dev] [ietf-dkim] Authorizing List Domains
Murray S. Kucherawy
msk at cloudmark.com
Wed Sep 29 11:15:34 PDT 2010
> -----Original Message-----
> From: Douglas Otis [mailto:dotis at mail-abuse.org]
> Sent: Tuesday, September 28, 2010 7:01 PM
> To: Murray S. Kucherawy
> Cc: dkim-dev at mipassoc.org; ietf-dkim at mipassoc.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?
> 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.
More information about the dkim-dev