Re: [ietf-dkim] A more fundamental SSP axiom

Douglas Otis <dotis@mail-abuse.org> Thu, 03 August 2006 15:21 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8f0r-0006uc-3d for ietf-dkim-archive@lists.ietf.org; Thu, 03 Aug 2006 11:21:29 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8f0p-0004C2-Lp for ietf-dkim-archive@lists.ietf.org; Thu, 03 Aug 2006 11:21:29 -0400
Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k73FJlne029025; Thu, 3 Aug 2006 08:19:48 -0700
Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k73FJgSs028977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-dkim@mipassoc.org>; Thu, 3 Aug 2006 08:19:42 -0700
Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k73FJE20028490 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 3 Aug 2006 08:19:14 -0700
Subject: Re: [ietf-dkim] A more fundamental SSP axiom
From: Douglas Otis <dotis@mail-abuse.org>
To: dcrocker@bbiw.net
In-Reply-To: <44D1675E.6020405@dcrocker.net>
References: <20060802002353.U59653@simone.iecc.com> <44D0E259.7040400@mtcc.com> <20060802165510.X1168@simone.iecc.com> <44D160BD.7080209@mtcc.com> <20060802223619.E86316@simone.iecc.com> <44D1675E.6020405@dcrocker.net>
Content-Type: text/plain
Date: Thu, 03 Aug 2006 08:19:13 -0700
Message-Id: <1154618353.2439.46.camel@bash.adsl-64-142-13-68>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4)
Content-Transfer-Encoding: 7bit
X-Songbird: Clean, Clean
Cc: DKIM List <ietf-dkim@mipassoc.org>
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
X-SongbirdInformation: support@songbird.com for more information
X-Songbird-From: ietf-dkim-bounces@mipassoc.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc

On Wed, 2006-08-02 at 20:02 -0700, Dave Crocker wrote:
> 
> John L wrote:
> > The third is "<foo> signs all my mail", if it turns out that there
> > actually exist foo's that reliable enough to delegate's one's signing,
> > and that it's easier to do that than to sign in the MUA or to provide
> > signing keys so that foo can put on the sender's signature.
> 
> Outsourcing for mail sending is already common, so it seems likely that
> delegating signing would be, too.
> 
> But my question is why it is better to have a "delegation of my domain" scheme
> rather than simply having the outsourced sending do its own signature and then
> use its domain name for evaluating its own reputation.  If it is a Good Actor,
> then it shouldn't need to rely on the domain name of the content author.  If it
> is a Bad Actor, then relying on the domain name of the content author would
> merely wind up hurting the content author.

One should assume that the recipient _can_not_ recognize the From
email-address.  However, one could also assume that the MUA _can_
recognize an "accepted" the address when annotating the message.  Also
assume the annotation is distinctive in some fashion and can be reliably
recognized by the recipient.  This overcomes the issue of only
display-names being visible, look-alikes, and internationalization or
the recipient paying more attention to HTML content.  This is a High
Impact, High Likelihood concern.

To assist the MUA recognition process, an extremely useful piece of
information will protect the "acceptance" process.  Is this signature
considered "authoritative" by the From email-address domain?  This
suggests that the "authoritative" signing domain _is_ considered to be
doing the right things.  The right things might be authenticating the
sending account and verifying reception of the email-address before
permitting its use by this account.  While the recipient may wish to
override this requirement, they would be doing this at their peril. 


> > So my suggestion would be to use a format similar to the one we use for
> > the signatures, put the first two items in the spec, and use a syntax
> > that permits people to experiment with new items and propose the useful
> > ones for later standardization.
> 
> Something this minimalist does indeed seem like the best approach:  1)
> standardize a publication mechanism for an extensible list of practices; and 2)
> include a tiny number of extremely interesting practices to publish, to seed the
> effort.

Actually there is something even more minimal.  The "I sign all mail"
and "I send no mail" and "Foo signs my mail" can be answered using a
list and a single flag.  The flag would indicate that "I do not use
non-designated sources that may or may not sign"  or in other words,
"All my mail is signed by designated sources."  In Hectors view, this
flag represents a statement "Treat non-designated signatures with
extreme prejudice."

"I send no mail" would be an empty list and a flag.

"Just I sign all my mail" would be I's domain and a flag.

"Just Foo signs my mail" would be a list with Foo and a flag.

"Just Foo and I sign my mail" would be list with Foo and I and a flag.

"Don't expect all my mail will be signed, or signed by designated
signing domains" would be an empty list and no flag.  This would be the
default when no policy is found.

"Foo and I and other may sign" would be a list of Foo and I and no flag.
This should be the recommend method of indicating designated domains and
avoiding unexpected prejudicial treatment. Only heavily phished domains
might consider setting the flag, even though Hector may insist
otherwise.

-Doug       




> d/

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