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

Douglas Otis <dotis@mail-abuse.org> Sat, 05 August 2006 22:30 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Uel-0001WM-GP for ietf-dkim-archive@lists.ietf.org; Sat, 05 Aug 2006 18:30:07 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Udp-00075j-Q8 for ietf-dkim-archive@lists.ietf.org; Sat, 05 Aug 2006 18:29:11 -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 k75MPwsS003442; Sat, 5 Aug 2006 15:26:00 -0700
Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k75MPlen003424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-dkim@mipassoc.org>; Sat, 5 Aug 2006 15:25:48 -0700
Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k75MPMno001740 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 5 Aug 2006 15:25:22 -0700
Subject: Re: [ietf-dkim] A more fundamental SSP axiom
From: Douglas Otis <dotis@mail-abuse.org>
To: Hector Santos <hsantos@santronics.com>
In-Reply-To: <00cd01c6b8c0$a1f49470$0201a8c0@hdev1>
References: <20060805011337.73202.qmail@snake.corp.yahoo.com> <20060805014139.72093.qmail@simone.iecc.com> <20060805044640.74696.qmail@snake.corp.yahoo.com> <1154788208.2439.72.camel@bash.adsl-64-142-13-68> <00cd01c6b8c0$a1f49470$0201a8c0@hdev1>
Content-Type: text/plain
Date: Sat, 05 Aug 2006 15:23:35 -0700
Message-Id: <1154816616.2439.195.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: Mark Delany <MarkD+dkim@yahoo-inc.com>, 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: 5011df3e2a27abcc044eaa15befcaa87

On Sat, 2006-08-05 at 14:54 -0400, Hector Santos wrote:
> From: "Douglas Otis" <dotis@mail-abuse.org>
>
> > The default assumption of a listed domain in the policy would be to
> > assume "I sign all".  This could even be called the "I sign all" list.
> > The only embellishment needed would be the "Only". The default policy
> > when none is found would be an empty list with the assumed "I sign all"
> > assertion.
> 
> +1.
> 
> In terms of the DSAP draft syntax:
> 
>     OP=ALWAYS; 3P=NEVER;     # Only "I" sign mail
> 
> or
> 
>     OP=ALWAYS; 3P=ALWAYS;    # "I" sign mail
>     3PL=;                    # defined, but empty list;
>
> In terms of the SSP draft syntax:
> 
>    o=!  # All mail from the entity is signed; Third-Party signatures
>         # SHOULD NOT be accepted
> 
> But the SSP I-D stills has the "semantics" argument of what is meant by
> "Third-Party signatures SHOULD NOT be accepted."  I took this to mean 100%
> exclusivity. Apparently that is not what it means.  Hence one of the reasons
> for a "Fill in the holes" DSAP I-D proposal

A major benefit regarding a DKIM From policy is in facilitating
relationships between different From and signing domains.  Other methods
involve greater coordination between DNS and email providers.  Zone
delegation or selector/key arrangements are not easily achieved with a
simple "fill in the blank" style questionnaire.  Zone delegation or
key/selector arrangements likely require an arrangement of trust beyond
the immediate customer to achieve the needed transaction.  This
additional element of trust will likely act as a barrier to greater use.

Imagine that an organization certifies DKIM signing domains as doing the
"Right Thing".  The "Right Thing" might be using authenticated SSL 587
port submissions, where the From address has been vetted in some
fashion.  This vetting might be acknowledgments of receipt as commonly
used for mail-lists, or anything deemed trustworthy by the
organization. 

In the event that this mode of delegation "by way of policy" becomes
popular, an assertion that Foo signs for Bar may be fairly common.  Your
terminology attempts to make assertions specifically related to the From
domain separately from that of other listed domains.  This fails to make
a clear distinction for a listed domain. With your terminology, the
listed domain is easily confused as being some undefined signer, which
is not right.  It seems safer to include the From domain _and_ the other
listed domains into just one category of Designated Signing Domains.
Any domain listed in the DKIM From policy would be a Designated Signing
Domain.  Apply _any_ assertion to this entire DSD category.

The default assertion for _any_ listed domain is "Always Signs".

There Foo indicates they always sign.
"DKIM-FP: Foo"

It would confusing to use a 3PL entry to indicate no other signature
unfriendly services are being used that might perhaps originate a
message using the From domain.  Here a flag, perhaps at the end of the
list, could make this stipulation.  Call this the Only, Exclusive,
Closed-ended, or Complete-List flag.  To illustrate, this flag is "." or
(FULL STOP).

The "Only" Flag stipulates that no other services are used. Further
examination of possible e-invites or mailing lists are require or
desired, as they are not used.  This policy would be something like:

"DKIM-FP: Foo, ."

Sends no mail would be:
"DKIM-PF: ."

May or may not sign would be:
DKIM-FP: "

Both Foo and Bar sign (for Bar) would be:
DKIM-FP: Foo, Bar"

-Doug
 
 



  





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