dkim-dev
[Top] [All Lists]

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

2010-09-28 18:00:27
-----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