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