Re: [ietf-dkim] Re: ISSUE 1547: SSP-02: MX Record publishing mandateto r

On Feb 15, 2008, at 11:05 PM, Hector Santos wrote:

> Douglas Otis wrote:
> > On Feb 15, 2008, at 3:49 PM, Damon wrote:
> > > Just in case we need a tie breaker... -1
> > To summarize, as a bunch of -1 says so little, ...
> I know, don't you hate that. :-)  I call it the "Follow the  
> Chieftain Syndrome"   In my opinion, if "votes" came with some  
> reason or explanation for the position, it might help sway others.
> > .... the push back generated by this concept had to do with DKIM  
> > policy being applicable to other transport protocols that might be  
> > bridged into SMTP.
> Doug, for the record, I was more against the MX lookup MUST in the  
> SSP record discovery setup.   IMO, I prefer it to be a MAY or even a  
> SHOULD only because historically it was not a requirement and  
> therefore highly possible that the MX did not exist.
While the horse died before leaving the barn, the MX mandate  
(discovery record) would have been imposed only on domains that:
 1) implemented DKIM and
 2) published a DKIM policy record.

This scheme did not impact domains not publishing DKIM policy  
records.  You are correct, MX record may never be published in some  
cases, but it would be nice to impose a simple limitation on domain  
tree walking for polices.
By mandating that a discovery record (MX in the case of SMTP) be  
published along with policy records, just the existence of these two  
records provides a means to detect fraudulent use of a domain without  
examining record content.  This approach tolerates policy record  
format changes, while still safely minimizing the impact of a daily  
onslaught of spoofed references to existing domains that do not even  
handle messages.  The mandate would have offered a means to squelch a  
series of policy and key transactions in such cases.  An invalid  
signature may occur for many reasons, which leaves this result  
category significantly weaker than finding a domain publishing a  
policy record without also publishing a discovery record.
Technically, this approach creates a problem when the domain uses DKIM  
and publishes the policy record, but then does not support SMTP.  When  
their messages are converted by a protocol gateway to SMTP, a policy/ 
discovery record check would detect SMTP is not supported.  While the  
return path instantiated by the protocol gateway could provide a  
conversion for DSNs, the domain of the return path would be unrelated  
to the DKIM signature.  So yes, while this might be seen as a  
disadvantage, it also closes an avenue for abuse not controlled by  
DKIM.  This limitation would induce an assurance of a direct return  
path or the domain would be indicating they don't want a protocol  
translation.  This gives the originating domain greater control, where  
dummy records might be published to achieve the desired effect.
> Keep in mind the steps in SSP is only a recommendation. As long as  
> the end result is the same, people don't have to follow those steps.  
> It is very possible the MX lookup was already been done in other  
> places.
An MX (or some record) was to be queried when a policy record is not  
found to check the existence of the domain.  If an MX record had been  
accessed recently, then it could be in the cache.  Had there been a  
mandate to publish policy and discovery records together, then there  
would be a greater advantage in checking the MX record.
> Look at this way, the way I view it, if we keep the MUST MX lookup  
> requirement for the SSP discovery steps, then +1, I would agree  
> there should also be a MUST for adding/having a MX record for any  
> x822.From domain used in a domain's new DKIM signing mail operations.
The logic would be the other way around, but it would seem the WG  
wishes to keep all options open.  By adding scope to the policy  
record, the same effect is possible with somewhat larger policy records.
> So I have less of a problem with the idea from a general DKIM  
> deployment recommendation for domains to consider and even possibly  
> a SHOULD recommendation for having an MX record for x822.From from  
> the standpoint of "DKIM/SSP protocol consistency" especially when it  
> differs from the return path or sender domains.
This represents the minority view however. : (

> > The ability to clearly indicate whether any message is fraudulent  
> > without incurring additional transactions is also important from a  
> > general domain protection standpoint.  Jim is right.  Policy can be  
> > made to include scope, and that also offers a more flexible and  
> > workable solution.  Message abuse will demand negotiated changes  
> > accommodated to some extent by policy assertions.  Keeping a lid on  
> > the the added overhead represents the remaining challenged.
> +1, You're right. This is a very important part (for me) in the  
> implementation considerations.
> But consider, before you can mandate an x822.From MX with a MUST,  
> you also have to, at the very least, allow for verifier policy based  
> handling and that has been removed in the current emasculated model.
By pairing policy/discovery records, the content of the policy record  
does not matter in preventing the spoofing of existent domains that do  
not support SMTP.  On the other hand, the term "discardable" instead  
of "strict", "sole", or "exclusive" or words to that effect, means  
transactional domains wishing to thwart spoofing are instead likely to  
find too much of their communications lost.  It will take some time  
for signature integrity to mature.  This problem is not just due to  
mailing-lists.  The "discardable" term will likely ensure the needed  
level of integrity never occurs.  Much of the essential feedback on  
whether the domain is being spoofed, or whether there is a signature  
integrity problem is likely to be lost.
> Since policies allowed implementators to optimize and scale DKIM  
> processing, its removal reduces the MDA adoption incentive for DKIM  
> verification. Thus, with little to no payoff resulting from the  
> additional overhead, there is less reason to even bother with the  
> overhead.
DKIM has value at the MUA where scaling and overhead is much less of a  
problem.  The triage process at the MTA could be guided by policy  
assertions.  DKIM validation at the MTA may be limited to domains with  
a history of being targeted by abuse.  When these domains are  
unwilling to make signature assurances, filtering must be relaxed to  
reduce the rate of false positives.  In this regard, there appears to  
be agreement SSP-01 was a better in that respect.  There does not seem  
to be a problem when signatures are added by third-parties however,  
while admitting to not understanding all of that thread.
-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html