Subject: [ietf-dkim] How to proceed with SSP

From: DKIM Chair <[email-masked]>
Date: Wed, 26 Jul 2006 08:55:13 -0400

We have Internet-Drafts from Phill and Doug, as well as the now-expired
-allman-ssp draft, which Jim is working on an edit to resubmit, so it
soon will no longer be expired.  Note that the new draft will still be
-allman-ssp for now, not -dkim-ssp.  So how will we proceed?

Dave suggested in Montréal, to the agreement of at least some
(including the chairs), that we have to step back and sort out SSP
*requirements* before we can do an SSP specification.  Mike has
volunteered to put together a first pass at that, which he is working
on feverishly as I type this (OK, I'm typing this at 5:40 in the
morning his time, so that's probably an exaggeration, but you get the
point).

Therefore, here's the plan:
* Mike will put out a requirements draft, which we will approve as
"draft-ietf-dkim-ssp-requirements-00" (Mike, take note of the name, and
be sure to copy "[email-masked]" when you submit the I-D).
This document will go through whatever iterations are needed to get
rough consensus, but will most likely remain a draft, and eventually
expire (no RFC).  Its purpose will be to lay the foundation for a
"draft-ietf-dkim-ssp-00" document, which will be the standards-track
spec.

* The proposals that are out there now (the three drafts I mentioned
about), along with any others that people want to float, will be input
to the requirements discussion.  What the ultimate -dkim-ssp-00 doc
will look like after that is anyone's guess right now.  That's why we
need to hash out the requirements.

* We aim to have consensus on the requirements some time in September
(we'd like to be optimistic, and say "mid-Sept" rather than "end of
Sept").  At that point, we'll see where we are, and either use one of
the "individual" drafts as a basis or appoint a design team to write a
new draft.

* That gives us a draft spec by the end of September or so, which has
at least rough consensus that it fits the working-group's requirements.
We'll have time before and during the San Diego IETF meeting to work on
it, and then we can wrap it up after.  The goal will be to send it to
the IESG as a Christmas present.

Plan-bashing is welcome, but any suggestion that we don't need to do
the "requirements" step will have to put forth a Very Strong
explanation as to why not.  Meanwhile, we await Mike's first
requirements draft with bated breath.

I'll note that we'll work on the overview document in parallel with
SSP, but that SSP takes priority.

Barry

--
Barry Leiba, DKIM working group chair  ([email-masked])

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

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 26 Jul 2006 09:41:51 -0500

> *requirements* before we can do an SSP specification.

I am in full agreement with this plan and am happy to see that an 
approach is being managed and is well thought out.  You're right, what 
SSP ends up looking like is anyone's guess at this point but with a 
pre-determined requirements doc to work from it will help the process 
greatly.

-- 
Arvel

---

From: Douglas Otis <[email-masked]>
Date: Wed, 26 Jul 2006 08:44:44 -0700

> morning his time, so that's probably an exaggeration, but you get the

A major objection received from the approach regarding listing
"designated signing domains" using a PTR RR was due to incorporating the
list syntax of "*.", and "." and the concern that although this would be
restricted to a specific underscore label, bad implementations might
consider this syntax to be valid host names.  A similar problem occurred
with the "." used with SRV records.

One solution for this problem would be to combine two different RR
record types or to create a specific RR that combines both a name list
and rather simple set of policy assertions reflected by that syntax. A
name list overcomes several difficult administrative issues related to
using the signing services of a large organization allowing users the
freedom to include their desired email-address within the "originating"
header.

The current SSP syntax is overly complex. The possible weighting of the
dubious states also appear easily structured to punish domains without
conforming policy assertions.  This outcome should be avoided.  The
approach should be extremely sensitive to administration overhead and
support efforts.  In addition, policy searches or user level policy may
represent an inordinate amount of traffic, especially when applied
against more than one identity per message.

As DKIM depends upon some type of annotation to convey verification
results, the dispensation of identities without direct policy can be
dealt with by way of specific annotation.  This might represent a
special folder reserved for messages with matching OA and signing
domains for example.  This treatment could include designated signing
domains as well. 

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 26 Jul 2006 16:24:54 -0400

J.D.

It is about expectations.   The world is being ask to being looking at the
broadcasting of DKIM messages coming into their system.

What do you (speaking in general) expect us to do?  Define it.

The engineering shows there is a fix set of boundary conditions.  Based on
the specifications, these are inherent to the model.   They are there to be
used.

However, we can control them.  What is acceptable and not acceptable.

John is calling for a low footprint of the boundary conditions.  He suggest
"Always Sign" and "No Mail" expectations.

I believe for the sake of progress that it is probably feasible to begin
with a base SSP draft concept that strictly deals with the original domain
boundary conditions.

I see this OA policies:

     No Mail Expected
     Never Signed by anyone
     Optional Signed by Original Domain (today called Strong)
     Always Signed by Original Domain (I call this Exclusive Policy)

A network may want to have an always sign and a sometimes signed, but in all
cases, if signed, it is OA only.

I think one this is squared away, then we can introduce the next 3PS SSP
boundary conditions which is be HIGHLY complex and not only domain policy
based but also ISP based, List Server Based and other 3rd party middle ware
services, etc.   There is where the potential liability and contractual
concepts come into play  and  no doubt, it can be complex because for the
most part it begins to introduce the idea of having a list of authorized 3rd
party signers.

---
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "J.D. Falk" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 26, 2006 3:10 PM
Subject: Re: [ietf-dkim] How to proceed with SSP

> pre-determined requirements doc to work from it will help the process

+1

Policy is different things to different people -- and like many
social/legal/political constructs, the same policy can contradict itself
without being invalid.  This won't be an easy consensus to find.

--
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 26 Jul 2006 12:10:12 -0700

+1

---

From: Dave Crocker <[email-masked]>
Date: Thu, 27 Jul 2006 05:52:55 -0700

> without being invalid.  This won't be an easy consensus to find.

That's why I keep suggesting we use the term "Practice" rather than "Policy".

"Practice" is both mundane and behaviorial.  None of the abstraction, emotion or
politics "Policy".

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html