Subject: [ietf-dkim] +1 on requirements for ssp-like-thing

From: Michael Thomas <[email-masked]>
Date: Wed, 12 Jul 2006 12:18:35 -0700

I'm not sure that Dave Crocker and I are in full agreement, but it's 
close enough
that it should make people worry. Even though I've been thinking about 
SSP for
a long, long time (IIM had the same concepts), it's not entirely clear 
to me that
we know what problems we're trying to solve or whether they're worth 
solving.

As far as I can tell, there are only a couple that have some obvious 
constituencies:

1) I sign everything, for some value of everything
2) I don't send email at all.

All of the others are rather debatable -- and have been often. What 
would be good,
I think, is to actually have problem statement for each new need for 
policy/practices
advertisement, who would use it, why they would use it etc. The current 
draft, IMO,
has too much of a "if you build it they will come" flavor to it, and 
most especially
with respect to the "third party" stuff which I don't sense there's any 
real agreement
on what it mean, or what problem it actually solves. In fact, I'm fairly 
certain as
current specified, the "-"  solves nobody's problems.

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 12 Jul 2006 15:56:40 -0400

On Jul 12, 2006, at 3:18 PM, Michael Thomas wrote:

>
> I'm not sure that Dave Crocker and I are in full agreement, but  
> it's close enough
> that it should make people worry. Even though I've been thinking  
> about SSP for
> a long, long time (IIM had the same concepts), it's not entirely  
> clear to me that
> we know what problems we're trying to solve or whether they're  
> worth solving.
>
> As far as I can tell, there are only a couple that have some  
> obvious constituencies:
>
> I think, is to actually have problem statement for each new need  
> for policy/practices
> advertisement, who would use it, why they would use it etc. The  
> current draft, IMO,
> has too much of a "if you build it they will come" flavor to it,  
> and most especially
> with respect to the "third party" stuff which I don't sense there's  
> any real agreement
> on what it mean, or what problem it actually solves. In fact, I'm  
> fairly certain as

The policy/name-path approach provides two advantages:

1) Reduce grey-list exceptions when the OA != signing domain.
2) Improve status of messages where OA != signing domain, but where a  
signing domain is authorized by the OA domain.

A small enterprise could utilize a major provider's DKIM signing by  
posting domains a domain list (similar to PTR RRs) they authorize for  
signing their messages.  A copy of the provider's public key still  
requires administrative arrangements or delegations, which  
complicates key management and increases the related expenses.  In  
addition to reducing the management of the keys, the path name would  
offer a defensive strategy permitting selective delays be injected  
when associations are not obvious, and where the source has not sent  
sufficient legitimate traffic to become white-listed.  A delay may be  
vital for block-listing for replay abuse, for example.  These name  
path lists can be declared open/closed/shut to cover the "basic"  
constituencies (large one-name domains) while also improving upon the  
applicability of DKIM for smaller entities.  This could be done with  
a new type of PTR RR that has a 16 bit field for binary assertion  
flags, and a host name field.  Currently, two or three bits could  
cover today's current states related to DKIM.  Two bits of the policy  
field might define the RRset to be open/closed/shut.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Wed, 12 Jul 2006 14:17:04 -0700

> The policy/name-path approach provides two advantages:

[]

This illustrates exactly what I think is wrong here: we have lots of 
solutions
to undefined problems.

       Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 14 Jul 2006 13:46:34 -0600

> 2) I don't send email at all.

I'm sorry I had to miss the meetings in Montreal.

I want to put forth my belief that, whatever form SSP ultimately takes, 
being able to say "everything that uses my domain name in the From 
header can be expected to contain my digital signature" seems the rock 
bottom minimum requirement (at least for me).  Anything more might be 
nice, and I probably want some of it too, but we at least need this much.

Arvel