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

On May 26, 2010, at 8:16 PM, Patrick Peterson wrote:

> On May 26, 2010, at 12:02 PM, Steve Atkins wrote:
>
> > > ADSP doesn't claim to solve "phishing", it just allows bit-for-bit
> > > domain names to be safely tossed if they don't have a signature. How that
> > > integrates into the larger anti-phishing modules is frankly where the secret
> > > sauce lies for vendors.
> > We can't usefully discuss things like best practices or a revision of
> > the spec without some sort of concrete operational use case.
> >
> > <snip>
> > And that leads to... what is the intended main purpose? Without
> > that, there's no way to decide whether the suggested changes
> > will improve things, or simply cause it to be more broken (via
> > increased complexity leading to reduced usage or incorrect
> > usage, for example), nor to provide appropriate advice on
> > deployment (other than "Don't, yet.").
> ADSP as defined in RFC 5617 is the best place I know of to define ADSP's main 
> purpose, namely: to enable senders to advertise policies related to how they 
> would like unsigned messages to be handled and to aid receivers in assessing 
> unsigned messages from such senders.
> 5617 excerpts include:
> "DomainKeys Identified Mail (DKIM) defines a domain-level
>   authentication framework for email to permit verification of the
>   source and contents of messages.  This document specifies an adjunct
>   mechanism to aid in assessing messages that do not contain a DKIM
>   signature for the domain used in the author's address.  It defines a
>   record that can advertise whether a domain signs its outgoing mail as
>   well as how other hosts can access that record."
>
> "the legacy of the Internet is such that not all messages
>   will be signed, and the absence of a signature on a message is not an
>   a priori indication of forgery.  In fact, during early phases of
>   deployment, it is very likely that most messages will remain
>   unsigned.  However, some domains might decide to sign all of their
>   outgoing mail, for example, to protect their brand names.  It might
>   be desirable for such domains to be able to advertise that fact to
>   other hosts.  This is the topic of Author Domain Signing Practices
>   (ADSP).
>
> Perhaps you believe this purpose to be unclear, wrong or, perhaps, simply 
> wonderful. But I think the purpose stated in 5617 is a good place to start.
That describes the mechanics of what ADSP is currently defined to do, that's
all. It says nothing about *why*, other than "protect their brand names",
which is both ill-defined and something ADSP simply cannot do.

So it says nothing about the threat it's supposed to thwart. Without that
there's no possibility of creating an attack tree. And without that, there's
no possibility of doing any security analysis on any proposal. And ADSP
is (I think) primarily a security protocol...

I'm pretty sure that ADSP as-is is a bad tool to solve any particular problem.
But given it's not being proposed to solve any concrete problem, it's
hard to discuss whether there's a better solution. 

The original argument was that it would help deal with phishing, but
now even the strongest proponents are happy to explain that it will do
absolutely nothing to help with phishing - but go on to say that as it
won't help with phishing, the fact that it won't help with phishing isn't
a weakness.

So what actual operational problem does it attempt to solve? A byte
sequence in an email header field that's commonly not shown to the
user is not an operational problem. It might be a middle point in a
line of reasoning between an operational problem and ADSP.

Cheers,
  Steve


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html