On May 28, 2010, at 12:01 AM, Steve Atkins wrote: > > 1. Do we want to reduce the DKIM broken signature rate or do we want to make > ADSP less vulnerable to it. Or both, I guess.
I think both of those objectives are of interest. > > 2. If we want to reduce the DKIM broken signature rate, do we need to rework > DKIM at all I don't think so. > , or do we need to make operational recommendations to the generator and > signer of the mail yes > , or do we need to provide operational advice to forwarders and mailing list > managers yes > . For any of those we need to balance the improvement against the reduction > in deployment and reduction in correct deployment the increased complexity > will cause. The history of SPF-all and SRS is likely relevant there. > Why is guidance for how to use something that already exist make things more complex? It should dramatically reduce complexity through clear recommendations. Re-writing DKIM would be a problem, and I for one am not in favor of that as I agree with Steve that it will have a negative impact on deployments, but surely implementation guidance would only have a positive impact on deployments. > 3. If we want to make ADSP less vulnerable to it, this basically means > reworking ADSP such that it says that receivers should accept unsigned mail > in some cases - the various suggestions about accepting unsigned mail from > "trusted" mailing lists or forwarders. This is bound to open up a bunch of > theoretical security issues, and probably some real ones. I do not believe that is our only option. We can extend ADSP to provide a few new options over "all" and "discardable" that meet current use cases. Otherwise we could publish guidance to address expected use but I assume that guidance will leave it to the deployer to decide who and why they "trust" certain streams and/or policy assertions. > > 3a. If we go in that direction we're looking at making some fairly tricky > security related decisions. We'd need a proper analysis of the security risks > and operational benefits, which would require us to be more honest than we > have been in the past about what the end goals are, and how some of the more > obvious attack trees would affect those goals. > Maybe you are contemplating a different part of the elephant but I don't see what you are getting at with this line of rhetoric. > Any of those changes - i.e. doing anything other than accepting the seriously > broken behaviour and just documenting it - would require buy-in from the > chairs and other participants, and likely a charter clarification. I would not be surprised if we need a charter clarification to tackle adding options to ADSP, but aren't we already chartered to provide BCP guidance for the technologies that have come out of this WG? _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
