On 5/7/15 8:29 AM, Hector Santos wrote: >> On May 6, 2015, at 4:45 PM, Douglas Otis <doug.mtv...@gmail.com> >> wrote: >> >> Defending against DDoS is very difficult, but that was not the >> concern. Collateral damage would be of legitimate messages >> inadvertently blocked when removing a common DKIM signature. > > What do you mean by remove? You mean destroy, invalidate existing > signatures?
Removing signature information from DNS prevents an associated signature to validate as a feckless means to respond to signature delegation chain abuse. > Keep in mind this MAY be desirable, in fact the DKIM STD76 theory is > that resigners can occur blindly anywhere with the mail path. You > don't have destroy the original integrity during resign, yet that > transaction may be illegal (per policy) with the fact it has been > resigned. The concern relates to "delegating" with a DKIM signature fragment, where, when valid, authorizes signatures of a third-party. Even a "short" expiry likely covers several days or delivery may become fragile. It seems any delivery period would permit a sizable phishing campaign well beyond the control of a DMARC domain. TPA-Label provides a method to react to abuse while also minimizing collateral damage to other message streams that utilized the same DNS resources for their DKIM signatures. Of course TPA-Label could impose a similar list of no-change headers as found in a DKIM signature delegation. By leveraging a DKIM process, perhaps you might see that as simpler and offering more bang for the buck. >> There is also the challenge of managing a double-signature >> re-signing process where it must be assumed not all destinations >> receive a signature delegation. Even this double signing process >> may prove problematic when it goes beyond SQL query rates. > > SQL? <g>. Some folks are more optimized using ISAM/BTREE databases! Any interim per message special signing process is likely to encounter scaling issues especially when third-parties are handling tens of thousands of first party domains. Again, the TPA-Label approach does not introduce new signatures nor alter DKIM signature processing. It simply offers low frequency exceptions based on an asserted relationship between the From and third-party domain that can be instantly withdrawn by the From domain upon the detection of abuse. >> There is also another concern regarding any phishing campaign >> permitted by effectively signing unknown content. Only by removing >> DKIM signatures from DNS would a DMARC domain be able to squelch a >> phishing attack it inadvertently authorized. TPA-Label allows >> authorization removal to be based on the destination domain and >> even a specific list-id. TPA-Label would not impact any existing >> DKIM signing process since authorization by destination is managed >> by TPA-Label zones. > > Doug, we know a positive result of a DNS lookup will work. I > believe you wish to add more complex semantics on the parsing of > the lookup results, I believe that's ok. But we need a basic yes/no > query. Maybe it can be sold if we offer more bang for the buck on > each call but overall, it needs to be very simple. TPA-Label is simpler because it does not require third-party processes to be interspersed between each step of message handling. It involves only sender assertions and recipient exceptions. Instances requiring a reaction respond to abuse which TPA-Label can handle both promptly and with minimal collateral disruption. BTW, SPF -all was seldom used since it offered >1% false positive rates and with DMARC, it is even best considered ~all to allow DKIM a chance to rescue messages from rejection or spam folder placement. Regards, Douglas Otis _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
