ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Authorizing List Domains

2010-09-28 17:04:45
  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.

Agreed, but not having a defense against trivial exploitation of
an authorization is not better. When a defensive requirement
proves unused, it can be removed without impact. Since this
information sets authorization requirements, adding the information
at a later date would not be compatible with existing
implementations.

 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.

Perhaps we can work on the bare essentials independent of the
notation used.

Types of authentication that might be used for existing
third-party services-

1) DKIM 2) TLS 3) SPF 4) EHLO/ADR

 I wasn't aware we were scoping something intended to be universally
 used. My focus has been strictly on DKIM. Other than TLS, we're not
 talking about particularly strong authentication systems here so I'm
 not sure we should spend the cycles to be that accommodating.
 However, as I said before, decoupling ATPS from ADSP is a trivial
 matter if that turns out to be the right way to go.

DKIM is unable to unilaterally authorize third-party services which 
impedes use of restrictive acceptance criteria.  With few exceptions, 
DKIM/ADSP "discardable" disrupts normal email use, and ADSP/SPF "all" is 
ineffective at blocking spoofed domains.  TPA-Label can remedy 
inappropriate message rejection or acceptance while also avoiding 
discarded messages.

You seem to agree TLS could be included as a compliance option in 
conjunction with restrictive acceptance assertions.  TPA-Label offers a 
fallback to other authentication/verification methods for graceful DKIM 
methodology transitions.

While SPF does not authenticate a source domain, SPF "-all" currently 
represents the predominate restrictive acceptance assertion aimed at 
mitigating loss of email credibility caused by domain spoofing.  The 
TPA-Label scheme offers fallback options that don't wait for universal 
DKIM adoption to improve legitimate domain acceptance and spoofed domain 
rejection rates.

Perhaps TLS will be adopted as a means for IPv6 email acceptance based 
upon a domain, and might even become a governmental requirement.  After 
all, restrictive assertions requiring Author Domain DKIM signatures 
accompany the From header field is disruptive for most third-party 
services, when compared with restrictive SPF assertions.  In addition, 
DKIM signatures will not be as good at protecting domain reputations 
when compared with the use of TLS.

 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.

Additional header field requirements ensure message sorting or
presentation. The header field requirement is to offer simple
tactics against most phishing exploits:

a) Sender b) List-ID

 Why would one base any kind of security mechanism on a trivially
 spoofed header field?

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.

The most visible name to recipients is the domain found in the From
header, whether used as a basis for sorting, or when displayed in
addition to that of the friendly name.

 Then why create semantics around other fields?

The From header field is not strictly bound to specific email sources, 
especially for third-party services.  In reviewing the number of such 
sources involved, a dedicated effort at constructing comprehensive _tpa 
zones can fully encompass all legitimate sources and avoid most of the 
issues related with SPF and ADSP discardable/all.  Ensuring inclusion of 
Sender or List-ID header fields helps isolate third-party service mail 
streams and provides recipients a means to differentiate direct and 
indirect messages.

-Doug


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>