Re: [ietf-dkim] Re: New Issue: Do we need SSP record for DKIM=unknown?

On Dec 28, 2007, at 1:17 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
> > Rejections based upon the MailFrom IP address path failures,  
> > regardless of the asserted SSP policy, would diminish DKIM's  
> > delivery integrity.
> SPF FAIL users have had it with "delivery integrity", DKIM or  
> otherwise, they are determined to eradicate the backscatter at all  
> costs.  The proposal to use DKIM PASS as second opinion is from a  
> receiver's POV worried about "traditional forwarding".
> After the final dot of the DATA at the border is the last point in  
> time to arrive at a reliable decision wrt reject vs. accept.
DKIM requires acceptance of the message body.  DKIM's ability to offer  
reliable indications of misbehaviour will bolster that of content  
filtering results.  A connection blocking strategy fed with reliable  
information is commonly used for short periods to protect resources  
needed to process messages.  As such, DKIM can help overcome problems  
created by the unreliable application IP address path registration  
strategies.  Mitigating backscatter can be handled using TPA-SSP where  
a MailFrom's association with DKIM signatures can validate or  
invalidate issuance of DSNs.  DKIM can prove helpful at restoring  
integrity to SMTP, even after the dot. : )
> > TPA-SSP can better validate MailFrom
> | The application of TPA-SSP at the MailFrom represents an
> | entirely optional strategy which may or may not prove either
> | effective or practical.  The MailFrom scope is offered only
> | for experimentation.
>
> Please inform me about the outcome of the optional experiments, RFC  
> number, implementations, test suite, deployment, the works. What you  
> have at the moment is only a draft, it would be unwise to confuse  
> this with worldwide adoption.
This draft suggests a safer backscatter mitigation strategy that _is_  
compatible with DKIM, and fully independent of other strategies.
Including all used and unused client IP addresses, valid/invalid local- 
parts, handling requests, and record links within a record set has  
resulted in a bloated and incredibly dangerous sequence of DNS  
transactions.  These transactions are also highly dependent upon an  
unassured level of caching.  The "everything at once" approach  
represents a potential overhead that can well exceed that of accepting  
messages.  For DKIM to help restore SMTP delivery integrity (which can  
happen if a few things are fixed in SSP's current definition of a  
valid signature), reliance upon unreliable IP address path  
registration can and should be avoided.
> > A new resource record is not a solution, as both record types must  
> > still be published to ensure legacy compatibility.
> Existing SPF versions (in essence v=spf1 and spf2.0/pra) must do  
> this, future users of the now existing SPF RR are not forced to  
> replicate their policies in TXT records.  Or are you talking about  
> the problem with existing MS platforms and new RR types ? I hope  
> that this will go away.
A query for a typically non-existent resource record places a barrier  
for unlikely adoption of a new RR.  Rather than ensuring support for  
MS RPC translations, MS might even view demise of DNS an advantage, as  
their alternative is heavily patented.
> > and does not result in records that must contain "everything",  
> > including the kitchen sink.
> Apparently the SSP decision was:
>
> "We might want lots of info" => "we cannot share an existing RR",  
> "it has to work with TXT" => "we need our own label", and after  
> these decisions wildcards are not more trivial, tough.  But one of  
> the two premises ("lots of info") might be wrong, so far SSP needs  
> about 25 bytes - ignoring [FWS] for the moment, submitted as "SSP  
> issue".
Concerns remained regarding enterprise support of new RRs.  SPF now  
demands at least 10 linked records be permitted for each name  
validated.  The impact of IPv6 may cause this sequence to be further  
extended, where additional transactions will also be needed to resolve  
hostname addresses.  Using SPF to validate a DKIM domain in some  
manner might then impose this 10xplus sequence for each of several  
possible signatures.   The number of overall transactions could be  
staggering.
> > The issue involving wildcards really demands that SMTP should soon  
> > mandate publishing MX records to ensure message acceptance, at  
> > least for IPv6 in 2821bis. : )
> The Last Call ended 2007-12-24, and after five objections I did not  
> add this point again, and we failed to get support for this 2821bis  
> issue :-(
While not imposing change when consensus is not clear is  
understandable, a lack of a discovery record for assured acceptance  
can lead to serious DNS related risks.
> You can't build TPA-SSP on two rejected ideas, 2821bis will keep its  
> ugly address fallback also for IPv6 / AAAA.  It was a window of  
> opportunity because 2821 didn't mention AAAA explicitly, but I saw  
> to it that 2821bis does, so this window will be closed.
The entire email policy concept is affected, not just SSP or TPA-SSP.   
The alternative for asserting policy without an assured discovery  
record is to walk the DNS tree for A or AAAA records.  The lack of a  
specific discovery record represents a serious architectural  
extensibility defect for SMTP!
-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html