[dkim-dev] [ietf-dkim] Authorizing List Domains

[Murray S. Kucherawy]

> -----Original Message-----
> From: Douglas Otis [mailto:dotis at mail-abuse.org]
> Sent: Tuesday, September 28, 2010 3:02 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/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.