Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion

From: Brett McDowell <[email-masked]>
Date: Wed, 02 Jun 2010 14:46:05 -0400

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