Subject: [ietf-dkim] I-D ACTION:draft-ietf-dkim-overview-04.txt

From: [email-masked]
Date: Thu, 08 Mar 2007 15:50:04 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF.

	Title		: DomainKeys Identified Mail (DKIM) Message Signing Service Overview
	Author(s)	: T. Hansen, et al.
	Filename	: draft-ietf-dkim-overview-04.txt
	Pages		: 35
	Date		: 2007-3-8
	
DomainKeys Identified Mail (DKIM) associates a "responsible" identity
   with a message and provides a means of verifying that the association
   is legitimate.[I-D.ietf-dkim-base].  DKIM defines a domain-level
   authentication framework for email using public-key cryptography and
   key server technology.  This permits verifying the source or
   intermediary for a message, as well as the contents of messages.  The
   ultimate goal of this framework is to permit a signing domain to
   assert responsibility for a message, thus proving and protecting the
   identity associated with the message and the integrity of the
   messages itself, while retaining the functionality of Internet email
   as it is known today.  Such protection of email identity, may assist
   in the global control of "spam" and "phishing".  This document
   provides an overview of DKIM and describes how it can fit into a
   messaging service, how it relates to other IETF message signature
   technologies.  It also includes implementation and migration
   considerations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dkim-overview-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-dkim-overview-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dkim-overview-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tony Hansen <[email-masked]>
Date: Mon, 12 Mar 2007 07:47:30 -0400

> 	Title		: DomainKeys Identified Mail (DKIM) Message

As you read through this, you will find that the stuff in it dealing
with SSP is only part way there. This is hardly unsuprising since SSP
itself is only part where there.

An outstanding issue from the last IETF was (quoting the minutes):

	Tony Hansen reviewed the status of the DKIM Overview document,
	and we got another "hum" from the room about preference to put
	the document out soon, to aid implementations of the DKIM base,
	with a possible second version later, covering subsequent
	topics...  or to publish the overview document only after the
	working group completes (or largely completes) the rest of its
	work.  The consensus was again not overwhelming, and was
	marginally in favour of publishing a first version now.

Given the lukewarm consensus before about publishing this document now
versus later, we didn't push hard one way or the other for the latest
update.

However, I'd like to hear some discussion on the issue: Should we put
out a version now (without the SSP references), or hold off until SSP is
totally finished?

	Tony Hansen
	[email-masked]

---

From: Tony Hansen <[email-masked]>
Date: Mon, 12 Mar 2007 08:43:58 -0400

In other words, would folks prefer to:

A. Expedite publishing the Overview documents, in order to facilitate
development and deployment of the -base specification (with an update
later on for SSP), or

B. Defer the Overview document until the SSP specification is complete.

	Tony Hansen
	[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Mar 2007 14:52:00 +0100

> B. Defer the Overview document until the SSP specification is complete.

B.  I would rather see us put all of our efforts into concluding work on 
SSP.  Any distraction from that adds no functionality and will simply 
require revision when SSP is eventually complete, thus making more work.

Eliot

---

From: Hector Santos <[email-masked]>
Date: Mon, 12 Mar 2007 09:54:25 -0500

Hi Tony,

My technical and "product attraction" opinion is:

The original scope (SSP) was on track with addressing with what I 
believe were the most marketable features of the product:

    - High benefits for exclusive domain policies
    - High benefits in exposing the nature of domain usage

As a product producer, this is how I am going to be able to "help" the 
"world of domains" outside my own control. It is what I see my customers 
will desire, and at the same time, as a USER of the product, I would 
like to also protect my own domains being exploited and used at other 
compatible DKIM/SSP systems out there. I would rather that they honor 
our DKIM/SSP own policies.

We are simply not going to protect the entire spectrum of DKIM with no 
or flexible SSP policies.   But we can MOST definitely address domains 
(HIGH VALUE or not, but HIGH VALUE will probably be most interested) 
with "tigher" policies who simply do not expect MIDDLE WARE and/or LIST 
SERVERS to be "touching" or passing thru such mediums.

In effect, we want to provide "increased assurances" to the domains 
wanting to increase security value with direct communications with their 
end-users and target recipients.

In short, speaking as one vendor, we will not expose our customers with 
a "out of the box" DKIM solution until we have a SSP or similar concept 
wrapper concept.  I see absolutely no value in a DKIM-BASE only system 
and in fact, could hurt more than it helps and the longer DKIM-BASE is 
used and ignored, the more it becomes obsolete.

So if all possible, I "vote" for concurrent (or near) release of both 
specs, whatever that means in terms of IETF. I think Jim Fenton's 
updated SSP-03 is good enough to start and it covers the "features" that 
I outlined in my own (now expired) draft DSAP which was strategically 
written to simply highlight the concerns.  With that, I support SSP-03 
rather than continue with DSAP.

--
HLS

---

From: John Levine <[email-masked]>
Date: 12 Mar 2007 16:09:25 -0000

>> A. Expedite publishing the Overview documents, ...

>SSP.

I'd rather publish an overview that covers DKIM without saying
anything about SSP, and do a revised version if and when SSP
coalesces.  DKIM is ready now, and it would be bad if there were a
perception that people needed to wait for SSP to start implementing
DKIM base.

R's,
John

---

From: [email-masked] (Wietse Venema)
Date: Mon, 12 Mar 2007 13:34:00 -0400 (EDT)

> out a version now (without the SSP references), or hold off until SSP is

I would not wait with an Overview document until SSP is ready for
prime time. I would encourage deployment of DKIM-base now so that
we can gain useful experience.

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Mon, 12 Mar 2007 10:47:11 -0700

>    - High benefits for exclusive domain policies

Benefit is a rather general term.  In marketing terms, a benefit  
could mean greater opening rates and fewer false positive detections  
as a spoof.  Both of these benefits occur without SSP.

It is dangerous to suggest recipients will soon expect protection  
with MTA filtering using some SSP policy assertion.  This method of  
protection is too prone to many types of visual attack.  This  
"benefit" also assumes recipients will remain unaware which email- 
address has been assured by DKIM.  For a mailing list, the email- 
address being assured will differ from that assured when signed by a  
first party.  Perhaps the mail-list is trusted enough to allow first  
party "policy conflicts" to exist within their messages.  Should the  
MTA operator make this decision for everyone?

In addition, SSP benefits will be nil when signing messages of public  
accounts such as "[email-masked]".  SSP acceptance benefits  
can be jeopardized by abusive replay.  A high benefit should include  
some means of protection.

>    - High benefits in exposing the nature of domain usage

Why would the nature of the message be placed into a generalized  
policy statement?  Whoever signs the message could make such an  
assertion on a per message basis.

> As a product producer, this is how I am going to be able to "help"  
> the "world of domains" outside my own control. It is what I see my  
> customers will desire, and at the same time, as a USER of the  
> product, I would like to also protect my own domains being  
> exploited and used at other compatible DKIM/SSP systems out there.  
> I would rather that they honor our DKIM/SSP own policies.

What happens when your customer happens to communicate through an  
IPv6 to IPv4 gateway?  What happens to messages when the IPv4 address  
resolves to ipv4-gateway.com and signed by my-domain.com?  Now  
imagine the signing is for public accounts that have been rate  
limited as a means to reduce abuse.  In this case, the signature  
still does not offer a basis for acceptance, as it remains easily  
abused if it did.

For replay abuse, SSP could offer some real value.  SSP could provide  
a safe means to authorize the transmitter of the message, where when  
the signature is found conjunction with a transmitter authorization,  
the recipient will have been offered a safe basis for acceptance.   
This would also prevent the signer's reputation from being damaged  
due to abusive replays as well.  It seems this is where SSP can offer  
real value.  For cases where transmitter authorization is not found,  
receiver side rate-limiting can be employed instead.

> We are simply not going to protect the entire spectrum of DKIM with  
> no or flexible SSP policies.   But we can MOST definitely address  
> domains (HIGH VALUE or not, but HIGH VALUE will probably be most  
> interested) with "tighter" policies who simply do not expect MIDDLE  
> WARE and/or LIST SERVERS to be "touching" or passing thru such  
> mediums.

Anything created with a high value should include some means of  
protection.  The ability to replay a signed message may place even  
"HIGH VALUE" signatures in jeopardy of no longer being white-listed.   
SSP can defend the benefit of DKIM by offering a safe means to  
authorize the transmitter.  Sender-ID does not offer a safe means.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Mar 2007 10:57:08 -0700

> we can gain useful experience.
I sure hope that -overview is not looked upon as a necessary ingredient
for developing/deploying -base. Because I don't think it is.

My preference is to wait and have one document that covers both.

       Mike

---

From: Steve Atkins <[email-masked]>
Date: Mon, 12 Mar 2007 11:05:51 -0700

> we can gain useful experience.

+1

We're also more likely to get DKIM widely deployed before there's much
real-world experience with SSP than after.

Cheers,
   Steve

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 12 Mar 2007 12:05:28 -0700

Having spent a day reading through the draft from start to finish I think it is hard to see how to untangle the two. 

Policy is a major motivation behind a lot of what is in the overview. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Thomas
> Sent: Monday, March 12, 2007 1:57 PM
> To: Wietse Venema
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Re: I-D 
> ACTION:draft-ietf-dkim-overview-04.txt
> 
> Wietse Venema wrote:
> > Tony Hansen:
> >   
> >> out a version now (without the SSP references), or hold 
> off until SSP 
> >> is totally finished?
> >>     
> >
> > prime time. I would encourage deployment of DKIM-base now 
> so that we 
> > can gain useful experience.
> >   
> I sure hope that -overview is not looked upon as a necessary 
> ingredient for developing/deploying -base. Because I don't 
> think it is.
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 Mar 2007 12:16:29 -0800

+1

--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 12 Mar 2007 12:06:26 -0700

I don't think we need to agree on the policy implementation to get overview out.

We do have to have agreement on the requirements. 

> [mailto:[email-masked]] On Behalf Of Wietse Venema
> Sent: Monday, March 12, 2007 1:34 PM
> To: [email-masked]
> > out a version now (without the SSP references), or hold off 
> until SSP 
> > is totally finished?
> 
> I would not wait with an Overview document until SSP is ready 
> for prime time. I would encourage deployment of DKIM-base now 
> so that we can gain useful experience.
> 
> 	Wietse

---

From: Eric Allman <[email-masked]>
Date: Mon, 12 Mar 2007 13:41:33 -0700

--On March 12, 2007 8:43:58 AM -0400 Tony Hansen <[email-masked]> wrote:

> A. Expedite publishing the Overview documents, in order to
> facilitate development and deployment of the -base specification
> (with an update later on for SSP), or
>

B.  But I think I'm going against the flow.

eric

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 12 Mar 2007 16:07:17 -0700

On 2007-03-12 11:05, Steve Atkins wrote:

>>> out a version now (without the SSP references), or hold off until  
>>> SSP is totally finished?
>>

+1

> real-world experience with SSP than after.

SSP is pointless if it scares everyone away from deploying DKIM at all.

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 12 Mar 2007 16:26:22 -0700

> for developing/deploying -base. Because I don't think it is.

In order to decide to deploy -base, one must understand not only its details, 
but the context in which it is supposed to operate.

The -base document does not provide a general systems-framework for 
understanding the role of -base, because that was not a goal for -base. 
-overview provides that framework.

More generally, the deployment of security-related protocols has a long 
history of being problematic.  Understanding why and how DKIM is a credible 
mechanism, in the face of that problematic history, also is not something 
-base was intended to provide, since it is a specification rather than a 
tutorial.  On the other hand, -base does help with that understanding.

And so on...

Deployment is not a technical issue, so much as a management decision issue.

-Base is not intended to help decision makers or designers of the framework 
into which DKIM will fit.  The -Overview document is intended to help with this.

For anyone who is serious about wanting to get DKIM used, I would think that 
they would want it used sooner, rather than later.  Anything that will 
facilitate the 'sooner' ought to be a straightforward choice.

In particular, I do not understand the idea of delaying something that can be 
of significant use for early-stage -base adoption, and waiting for some 
unknown moment in the problematic future, when SSP might eventually converge 
and get approved.

d/
-- 

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

---

From: Hector Santos <[email-masked]>
Date: Mon, 12 Mar 2007 19:51:49 -0400

> SSP is pointless if it scares everyone away from deploying DKIM at all.

It is totally ironic that there come could be two opposite viewpoints. 
Of course, one of us is going to be proven wrong. :-).

I tend to side with the high probability that blindly signing MAIL in a 
DKIM-BASE only manner (with no helper support, and I presume you are 
just against SSP, not other kind of helpers, like DAC or some other yet 
to be established reputation helper), will not only open the door for 
DOMAIN reputation damage but make DKIM as useless as the NO POLICY DRIVE 
DOMAINKEYS currently is in the wide public open market place.

If there is any proof that a DKIM-BASE only concept will be proven to be 
worthless (not widely adopted across the board),  all anyone has to do 
is look are DOMAINKEYS.

I take the position that if this issues are known as they are today and 
we fail to do something about it, then we acted irresponsibly.

--
HLS

---

From: Douglas Otis <[email-masked]>
Date: Mon, 12 Mar 2007 18:11:27 -0700

On Mar 12, 2007, at 4:51 PM, Hector Santos wrote:

> I tend to side with the high probability that blindly signing MAIL  
> in a DKIM-BASE only manner [...], will not only open the door for  
> DOMAIN reputation damage, but make DKIM as useless as [...]  
> DOMAINKEYS [...].

Where DKIM base concluded speaks well of DomainKeys.  Unless SSP  
provides a means to mitigate replay abuse, then one is advised to not  
base acceptance solely upon finding a valid signature from a  
reputable domain.  DKIM still prevents false positive spoofing  
detections and allows messages to obtain greater trust when the  
assured email-address is annotated.  Annotation is the _only_ safe  
and extensible solution for DKIM email, otherwise too many things break.

By reputation, are you suggesting recipients will not be assured when  
"seeing" an email-address, unless all without a valid signature are  
expunged through the application of SSP?  Security should not be  
based upon the visual acuity of the recipient.  What happens when  
UTF-8 is used, or multiple versions of an email-address are applied,  
or the From header contains more than one representation, or uses  
more than one character-repertoire?  What happens when the Sender  
header is assured instead of the From header?  Basing security upon  
what someone might see is not a safe solution.  Would there be a  
recommendation that no email-address be displayed using less than  
half the points of the recipient's age? : )

When reputation means the signature can be used as a basis for  
acceptance, then your scheme also fails to offer reputation  
protections.  SSP could be used to authorize transmitters for this  
purpose.  It could be used to authorize the sending of DSNs as well.   
There are many improvements SSP could provide.  Providing guidance on  
which messages with invalid signatures should be expunged is perhaps  
the most problematic goal to pursue which then only offers  
questionable security.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Mon, 12 Mar 2007 22:55:45 -0700

> B.  But I think I'm going against the flow.

+1.  I'd like to focus on SSP, but wouldn't rule out a draft (which 
wouldn't be published as an RFC) that contains deployment guidance in 
the interim.

-Jim

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 13 Mar 2007 09:49:10 -0400

+1

-- 
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com

---

From: Dennis Dayman <[email-masked]>
Date: Tue, 13 Mar 2007 09:03:24 -0500

+1

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 13 Mar 2007 16:08:51 +0100

> We do have to have agreement on the requirements.

That sounds like a good compromise.

Frank

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 13 Mar 2007 10:01:03 -0700

On 2007-03-12 16:51, Hector Santos wrote:

> to be established reputation helper)

Hmm, not sure who you're arguing with here -- can't be me, I'm not 
against SSP.  Never have been.  I just don't think it's a good idea to 
continue telling the world that DKIM isn't ready.

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 13 Mar 2007 13:28:51 -0400

> continue telling the world that DKIM isn't ready.

I don't think the 'world' understands that DKIM is just a building
block.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Mar 2007 10:46:56 -0700

> I don't think the 'world' understands that DKIM is just a building

That is one of the reasons for wanting to get the Overview document out 
sooner, rather than later.

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Tue, 13 Mar 2007 13:47:00 -0400

J.D. Falk wrote:
>> I tend to side with the high probability that blindly signing MAIL in 
>> a DKIM-BASE only manner (with no helper support, and I presume you are 
>> just against SSP, not other kind of helpers, like DAC or some other 
>> yet to be established reputation helper)
> 

We can probably drive a car with just the frame, engine, wheels, etc but 
no body yet and get good use of it.  You will be exposed to the elements 
of the world during the process of using it, but its usable.  Some 
people won't care and some people actually like the eating bugs.   Some 
will be excited to have it now.  However, I'm sure most people will 
prefer that there was "added security,"  "a helper,",  "a wrapper,"  "a 
blanket,"  "a body" that helps protects you from the elements.

So is the frame ready?  Sure, 100%, it still has its kinks. But is it 
ready.  I don't think anyone disputes that.

But is it ready for public consumption?  Has all the engineering been 
worked out so that its SAFE to be used in the public?  Does it present 
any liability issues?  Is an early release better with the risk of 
creation a wide tertiary market of "different helper" systems in the 
name of getting exposure and experience with this "frame-" work., or is 
better to have an augmenting IETF standard helper technology?

--
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 13 Mar 2007 14:01:19 -0400

> I don't think the 'world' understands that DKIM is just a building

I don't think the "world" understands that a building block does not 
mean it is a public consumption technology without the helper blocks.

In fact, putting out a "building block" before it the required parts are 
ready can do more harm than good.

The easiest issue to envision is that this can build a new legacy market 
of "DKIM-BASE" systems that now the receiver has to deal with.

Lets say you finally (by you, I am speaking in general), finally realize 
that DKIM-BASE by itself, although theoretically usable, it is not 
practical to be used on its own.  You realize you need something else 
before you can turn it on.

What then?  What are the rules for the receiver?

   - Support DKIM-BASE only systems?
   - Don't Support DKIM-BASE only systems?

This is exactly the same problem that the industry evolved to over the 
past two decades and what has brought us together here.   The problem is 
dealing with the legacy market of old SMTP systems and how the bad guys 
use this to gain entry into systems.  If that wasn't the problem then we 
would have FULL control of all anonymous transactions.

So by drinking your wine before its time, we risk wasting the potential 
of a promising technology being forced into the market place before 
essential elements are at the very least, settled for final development.

I'm not against DKIM-BASE. I'm against premature decisions that will 
ruin it.

--
HLS

---

From: Michael Thomas <[email-masked]>
Date: Tue, 13 Mar 2007 16:45:56 -0700

Dave Crocker wrote:
> history of being problematic.  Understanding why and how DKIM is a 
> credible mechanism, in the face of that problematic history, also is not 
> something -base was intended to provide, since it is a specification 
> rather than a tutorial.  On the other hand, -base does help with that 
> understanding.

Given the disagreements with how people view dkim as being used in
reality, I'd suggest that a dose of reality may be required before
the overview you seek has any chance at consensus. I've already seen
-overview being misconstrued by the Mailman folks to strip signatures
given some editorializing about that subject. And we know what happens
when we talk about those disagreements.

I've been a proponent for a DKIM BCP for a long time. I think that is
where -overview fits in, and it will make a huge amount of sense when
we actually have enough experience to make a BCP -- and that goes for
SSP as well. As it currently stands, there is far too much room for
speculation so I think it is pretty much a waste of time to be going
over the same set of arguments that we didn't overcome the last time.

As far as the hand-wringing about -base not being enough.. I just don't
buy it. We have a lot of implementations and deployments (esp. counting
DK) even with the paucity of overview material. So that's not the
problem. Nor does not doing -overview now prevent writing DKIM
evangelizing articles/papers/etc that fill that gap -- with as much
speculation as the author feels like dreaming up. So that's not the
problem either. So what is the problem that -overview is trying to
solve that _requires_ official IETF status *right now*?

		Mike

		Mike

> -Base is not intended to help decision makers or designers of the 
> framework into which DKIM will fit.  The -Overview document is intended 
> to help with this.
> 
> For anyone who is serious about wanting to get DKIM used, I would think 
> that they would want it used sooner, rather than later.  Anything that 
> will facilitate the 'sooner' ought to be a straightforward choice.
> 
> In particular, I do not understand the idea of delaying something that 
> can be of significant use for early-stage -base adoption, and waiting 
> for some unknown moment in the problematic future, when SSP might 
> eventually converge and get approved.
> 
> d/

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 14 Mar 2007 12:27:33 -0000

+1

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Powers, Jot" <[email-masked]>
Date: Wed, 14 Mar 2007 07:36:41 -0700

+1

> B. Defer the Overview document until the SSP specification is complete.

As the largest phishing target out there, we're interested in having DKIM be
out there as soon as possible, without waiting for SSP, because even "fast"
for the IETF process isn't particularly speedy, whereas spammers and
phishers are.

-Jot
-- 
Jot Powers             <[email-masked]>
Phone: 480-862-7234    Cell: 480-221-1157
Skype: jotebay

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Mar 2007 08:01:07 -0700

> for the IETF process isn't particularly speedy, whereas spammers and

Not to pick on Jot, but this is very illustrative of why putting
-overview in the path right now may be very counter-productive.
-Base *is* done. Waiting for -overview is *not* required. The
best possible wait time is the zero you can do by reading -base
right now and deploying it.

		Mike

---

From: Eliot Lear <[email-masked]>
Date: Wed, 14 Mar 2007 16:00:15 +0100

Jot,

The overview isn't keeping DKIM from the world.  In fact you guys can 
sign today, if you don't already (haven't checked).  The real question 
for me now is simply this: will those people who are writing the 
overview now commit to updating it after SSP is complete?  And I for one 
want to see SSP complete quickly.

Eliot

---

From: "Powers, Jot" <[email-masked]>
Date: Wed, 14 Mar 2007 08:07:36 -0700

> right now and deploying it.

Don't worry, I can take it.  :)

I almost wrote:

C:  Wait for nothing.

But I was trying to be a good little list member and only vote on the
options provided.

Just to be clear:

We would DKIM sign now (and did a while ago) if our appliance vendor
supported DKIM, which they plan on doing, once it is a "standard" for some
value of "standard".  (They have said summer '07)

Our approach is that we don't care about chicken's or eggs, we just love a
nice chicken omlete.  :)

-Jot

---

From: Dave Crocker <[email-masked]>
Date: Wed, 14 Mar 2007 08:11:11 -0700

Eliot Lear wrote:
> sign today, if you don't already (haven't checked).  

Eliot, you are, of course, correct.  But that rather misses the point.

The point is what will facilitate adoption.  (Why is it that the IETF works so 
hard to ignore adoption issues, as we think merely publishing a document is 
the end of the task?)

The Overview document, approximately in its current form (IMO), can be 
extremely helpful for the rest of the community, to understand DKIM and make 
deployment and use decisions about it.

 > The real question

Whether the current document is "updated", or a new document is written, or an 
overview section in the SSP specification itself is added strikes me as a 
decision to make at the time we need the additional writing.

I'm certainly happy to commit to putting in the effort to make sure there is 
text of an overview style for SSP.

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Mar 2007 08:19:52 -0700

> Our approach is that we don't care about chicken's or eggs, we just love a

I think this touches on the important question about all of this: what
are we trying to accomplish right now? My feeling is that we want as
quickly as possible to fertilize the fields with as many DKIM signers
as possible. This is a very straightforward proposition and -base
provides the necessary blueprint on how to do that. I really don't
think we need anything more elaborate than that (from an IETF
perspective, that is).

How receivers use the verification results will hopefully become a
lot more apparent once we have a critical mass of people signing, and
this is a *good* thing -- we're creating a tool, not a solution. When
that plays out, I think it would be very useful to document that, and
any SSP related practices into a BCP. That's what I've envisioned
-overview as being a start on: an eventual BCP.

		Mike

---

From: "Powers, Jot" <[email-masked]>
Date: Wed, 14 Mar 2007 08:20:28 -0700

> want to see SSP complete quickly.

It has come to my attention that perhaps I confused the discussions with
"fixing" -base due to the FWS stuff, and overview.

I read the discussion as having Overview be one of the solutions to this,
and thus holding up base, not SSP.  If that is the case, I apologize for
muddying the waters.

Regardless, I would like to see RFCs move forward (be it base or SSP)
without waiting for an overview document.

-Jot

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 14 Mar 2007 16:25:40 +0100

Powers, Jot wrote:

> supported DKIM, which they plan on doing, once it is a "standard" 
> for some value of "standard".  (They have said summer '07)

It is already an approved "proposed standard" - still waiting for its
RFC number, but that's mostly a formality.

> Our approach is that we don't care about chicken's or eggs, we just
> love a nice chicken omlete.  :)

Of course you love "soft" things as in SPF and PRA SOFTFAIL... <gd&r>

Frank

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Mar 2007 08:33:09 -0700

Dave Crocker wrote:
> The point is what will facilitate adoption.  (Why is it that the IETF 
> works so hard to ignore adoption issues, as we think merely publishing a 
> document is the end of the task?)
> 
> extremely helpful for the rest of the community, to understand DKIM and 
> make deployment and use decisions about it.

Who, exactly, is this "rest of the community"? I'd say that there
are at least two distinct communities:

1) software/hardware vendors as well as open source implementations
    writing DKIM
2) IT folks deploying (1)

 From what I can tell, (1) seems to be doing pretty OK with what we've
given them. Google's recent introduction of dkim signing seems to have
only required -base (actually -allman-01) to get them going. And google
isn't the only one who's digested the spec and popped out an
implementation.

As for (2), I suspect they are going to be taking their cues from (1).
Arvel's user base is a great testament of how (2) needs software that
makes doing the right thing easy. I don't think they need any deep
understanding of the motivations and mechanics -- and for Arvel's
customers an awareness that the IETF even exists :)

So I'm sort of dubious -- at this stage -- that either of these is
the *necessary* audience. Or is there some other necessary audience?
I can see this later as I've already written, but not now.

		Mike

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 14 Mar 2007 11:36:47 -0700

Absolutely. 

And the question that I raized was rather different. The question is whether we should publish a version of the overview with references to policy taken out.

I do not accept that we have to wait till completion of the policy specification to publish a version of overview. It is sufficient to have last call on the policy requirements. The overview document does not go into the details of how policy works, requirements are sufficient. 

> [mailto:[email-masked]] On Behalf Of Dave Crocker
> Sent: Wednesday, March 14, 2007 11:11 AM
> To: Eliot Lear
> Cc: Untitled; Powers, Jot
> The point is what will facilitate adoption.  (Why is it that 
> the IETF works so hard to ignore adoption issues, as we think 
> merely publishing a document is the end of the task?)
> 
> The Overview document, approximately in its current form 
> (IMO), can be extremely helpful for the rest of the 
> community, to understand DKIM and make deployment and use 
> decisions about it.
> 
> 
>  > The real question
> > overview now commit to updating it after SSP is complete?  
> And I for 
> > one want to see SSP complete quickly.
> 
> Whether the current document is "updated", or a new document 
> is written, or an overview section in the SSP specification 
> itself is added strikes me as a decision to make at the time 
> we need the additional writing.
> 
> I'm certainly happy to commit to putting in the effort to 
> make sure there is text of an overview style for SSP.
> 
> d/
> -- 
> 
>    Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Wed, 14 Mar 2007 16:28:51 -0400

Dave Crocker wrote:

>> overview now commit to updating it after SSP is complete?  And I for 
> Whether the current document is "updated", or a new document is written, 
> or an overview section in the SSP specification itself is added strikes 
> me as a decision to make at the time we need the additional writing.

I could be wrong, but I believe he was referring to backward 
compatibility issues with a new legacy market of DKIM-BASE only systems 
vs DKIM-BASE PLUS SSS systems.

> I'm certainly happy to commit to putting in the effort to make sure 
> there is text of an overview style for SSP.

Well, IMO, you talk about independent, value-added assessment services 
in a futuristic manner anyway, why SSP wasn't there or included in the 
first place speaks volumes about the true nature of the problem here.

FWIW, I am prime example of a target audience member your overview 
attempts to address.  I would probably be asking "what are these 
independent, value-added services, and do they exist today?"

--
HLS

---

From: Steve Atkins <[email-masked]>
Date: Wed, 14 Mar 2007 13:56:16 -0700

On Mar 14, 2007, at 1:28 PM, Hector Santos wrote:

>>> overview now commit to updating it after SSP is complete?  And I  
>>> for one want to see SSP complete quickly.
>> Whether the current document is "updated", or a new document is  
>> written, or an overview section in the SSP specification itself is  
>> added strikes me as a decision to make at the time we need the  
>> additional writing.
>
> compatibility issues with a new legacy market of DKIM-BASE only  
> systems vs DKIM-BASE PLUS SSS systems.

Are you suggesting that deploying SSP will break dkim-base? Could you  
explain how, if so?

Cheers,
   Steve

---

From: Hector Santos <[email-masked]>
Date: Wed, 14 Mar 2007 20:51:35 -0400

> Are you suggesting that deploying SSP will break dkim-base? Could you 

Yes and No.

The answer to your question depends on many factors, but it is really 
quite simple. This scenario is not new. Code Red and similar threats is 
based on the premise that there exist of market of old and legacy systems.

Given two sets of RECEIVERS:

   RECEIVER-A:  Legacy DKIM-BASE system. Supports DKIM-BASE only
   RECEIVER-B:  Updated to support DKIM-BASE+SSP

and given a DOMAIN that has determined that it "better" to use SSP than 
not use SSP, therefore it uses a strong SSP policy for signing.

then who do you think the BAD GUY will target?

   Simple:  RECEIVER-A

RECEIVER-A will bare the blunt of the premature decisions.  The DOMAIN 
reputation will be harmed because there exist a legacy of DKIM-BASE only 
systems that bad guys will target.

So using the word "break" is not a term I would use.  But I would say 
that the promotion and recommendation that it is SAFE to use DKIM-BASE 
without any helper technology is in my strong opinion, a very poor 
engineering decision because it HARM receivers and domains.

Of course, RECEIVER-A would have to upgrade and I believe that is 
question Mr. Lear was poising to Mr. Powers.  Will systems upgrade at a 
later point?

Of course, I think the answer is YES if such systems realize that its 
better to upgrade.  But we can only hope it is sooner than later so that 
we minimize the number of legacy of DKIM-BASE only systems.

Hope this helps

---
HLS

---

From: [email-masked] (Wietse Venema)
Date: Wed, 14 Mar 2007 21:05:52 -0400 (EDT)

> would have FULL control of all anonymous transactions.

Indeed. The evolutionary approach does not work. It has saddled us
up with a series of legacy systems that we need to cope with.

Instead, we need to get things right the first time. Therefore we
need to discourage deployment until we have achieved the complete
and perfect solution.  After that point has been reached, the world
will be perfect forever and nothing will ever need to be changed.

	Wietse

---

From: Hector Santos <[email-masked]>
Date: Wed, 14 Mar 2007 21:42:35 -0400

> will be perfect forever and nothing will ever need to be changed.

Of course, that is silly so I don't know why you brought it up.

Nonetheless, there is nothing wrong with having a "Getting right the 
first time" approach to design.  Its a QA thing, not an ABSOLUTE and if 
you do some research, you will find this old mantra is once again 
growing in engineering, management and QA circles.  The goal?  To 
minimize duplicity of rework, potential problems for you and customers 
and hence cost.

We are not talking about DAY 1 of the Internet here.  But 35+ years, and 
we have enough knowledge and insight to know today that if you can 
recognize the creation of a potential problem, then it would be 
neglectful if a) you didn't bring it up and b) if you continue to pursue 
such a course to allow it to happen.

--
HLS

---

From: Eric Allman <[email-masked]>
Date: Wed, 14 Mar 2007 19:14:13 -0700

--On March 14, 2007 8:11:11 AM -0700 Dave Crocker <[email-masked]> 
wrote:

> The point is what will facilitate adoption.  (Why is it that the
> IETF works so hard to ignore adoption issues, as we think merely
> publishing a document is the end of the task?)
>
> The Overview document, approximately in its current form (IMO), can
> be extremely helpful for the rest of the community, to understand
> DKIM and make deployment and use decisions about it.

I'm not saying that having some sort of overview document is a good 
thing for assisting with adoption.  I am saying that it doesn't need 
to be an RFC.  It can be just a draft, or (horrors) a non-IETF 
document.

I *am* saying that taking the time and effort to get WG consensus, go 
through Last Call, IESG Approval, and the RFC Editor queue is just 
overhead for now.  Wait until we have the whole thing before we go 
through the expense of formalizing it.

eric

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Mar 2007 20:25:33 -0700

On Mar 14, 2007, at 6:42 PM, Hector Santos wrote:

> We are not talking about DAY 1 of the Internet here.  But 35+  
> years, and we have enough knowledge and insight to know today that  
> if you can recognize the creation of a potential problem, then it  
> would be neglectful if a) you didn't bring it up and b) if you  
> continue to pursue such a course to allow it to happen.

DKIM represents a change in how message content can be identified.   
Placing information at the domain helps in preventing false-positive  
filtering of valid messages and allows more aggressive filtering of  
phishing attempts.  DKIM does not include any means to determine  
whether a transmitter is controlled by an affiliated entity, or  
whether there is a chance a message is part of campaign expending the  
signer's clout with abusive replays.  Perhaps a lower false-positive  
rate with a means to assure email-addresses is more than good enough.

DKIM serving as a basis for white-listing also depends on who is  
allowed to utilize the signing-domain.  Unless each person obtains  
their own signing-domain, DKIM signature abuse will likely preclude  
the general public from obtaining enhanced deliverability. : (

When everyone obtains their own signing-domain, tracking reputations  
will be difficult.  Everyone will also be in jeopardy of having their  
signature besmirched by replays of perhaps innocent messages, as  
tolerance for abusive replays may become wickedly low.

Bad actors are obtaining millions of new domains every day.  How many  
bad emails will it take before a signing-domain ends up on someone's  
do-not-accept list?  This could be worse than an IP address black- 
hole listing, as DKIM requires the signing-domain match that of the  
assured email-address.  Someone's email-address could easily become  
forfeit as a result of the abuse DKIM policy does not offer a means  
to control.  Not even your version SSP helps with this type of  
problem either.

While the Internet has been around for a while, the next few years  
will be bringing in many changes.  The only thing that remains the  
same is change.  It seems there are many possible scenarios ignored  
with your policy categorizations.  Bad actors are good at leveraging  
weaknesses that few thought would become a problem at the time.   
However, Edward Murphy is seldom wrong. : )

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Mar 2007 09:42:05 +0100

Hi,

I am more confused than ever, I suppose:

> quite simple. This scenario is not new. Code Red and similar threats 
> is based on the premise that there exist of market of old and legacy 
> systems.
>
> and given a DOMAIN that has determined that it "better" to use SSP 
> than not use SSP, therefore it uses a strong SSP policy for signing.
>
> reputation will be harmed because there exist a legacy of DKIM-BASE 
> only systems that bad guys will target.

First, I'm not sure how DOMAIN comes into this equation.  I suspect that 
RECEIVER-A will maintain a list of domains, either manually or out of 
band, that it knows signs messages, and may then weight messages from 
those domains with invalid signatures somewhat toward spam.  The only 
issue is that RECEIVER-A may not be able to make an easy decision about 
a message with an invalid signature from a domain that has no SSP 
record.  Perhaps it doesn't sign any mail.
> engineering decision because it HARM receivers and domains.

I just don't see this.

> question Mr. Lear was poising to Mr. Powers.  Will systems upgrade at 
> a later point?

No, my question was directed at Dave Crocker and Tony Hansen about 
whether they would be willing to revise the overview document.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Thu, 15 Mar 2007 04:07:32 -0700

Michael Thomas wrote:
> I think this touches on the important question about all of this: what are
> we trying to accomplish right now? My feeling is that we want as quickly as
> possible to fertilize the fields with as many DKIM signers as possible.
> This is a very straightforward proposition and -base provides the necessary
> blueprint on how to do that.

This is concisely stated.  I think it gets to the core view that many folk 
hold.  And, yes, I disagree with it.  But it's almost refreshing to disagree 
with such a clearly stated view.

I tend towards viewing wide-spread adoption as difficult.  Can't imagine where 
that perspective comes from...

Successful adoption of brand new IETF work usually entails quite a bit of 
post-standards marketing, as in "educating".  Getting folks on the same page 
about what to say is important and difficult.

The view that -base is sufficient presumes a) quite a high level of expertise, 
I believe, and b) quite a high level of effort.  Most managers and decisions 
makers, out in the larger Internet, do not have either.

Consequently, none of the folk in this working group are representative of 
that larger community. (Dare I note that even within the working group, there 
is often disparity on basic point about DKIM, which -overview ought to be 
useful in settling?

d/
-- 

   Dave Crocker

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 15 Mar 2007 10:07:51 -0400

On Thu, Mar 15, 2007 at 04:07:32AM -0700, Dave Crocker wrote:
> The view that -base is sufficient presumes a) quite a high level of 
> expertise, I believe, and b) quite a high level of effort.  Most managers 
> and decisions makers, out in the larger Internet, do not have either.

You seem to be saying that a top to bottom strategy is needed. For that
to happen you need to target Direct marketing publications. Writing an
overview doc posted on the net probably won't be read by upper
management. 

> that larger community. (Dare I note that even within the working group, 
> there is often disparity on basic point about DKIM, which -overview ought 
> to be useful in settling?

So who is overview really for? Management or implementors?

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 15 Mar 2007 14:23:20 -0000

> "fixing" -base due to the FWS stuff, and overview.

And speaking of the FWS stuff, I demonstrated that an actual BUG existed
in base, and Frank confirmed that, but there has been no response from
anyone in a position to fix it.

---

From: Hector Santos <[email-masked]>
Date: Thu, 15 Mar 2007 11:25:25 -0400

> record.  Perhaps it doesn't sign any mail.

Right, or the DOMAIN signs all mail and Bad Guys (BG) target legacy 
systems, including RECEIVER-A DKIM-BASE only systems with no signature 
mail purportedly from this DOMAIN   BGs will stay away from RECEIVER-B 
type systems.

>> engineering decision because it HARM receivers and domains.

Fair enough, it is just a consequence of the above which is not much 
different than today with BGs targetting legacy systems.  Receiver-A, 
including non-DKIM ready system will feel the blunt of the exploitation. 
     The unsuspecting domains, who unbeknowst to them, their domain is 
being used in vain at these sites (spoofed, phished), are harmed.   No 
different than it is today.   I'm just hoping that we don't begin march 
into a new era with the same mistakes of opening new holes due to 
incomplete considerations.

> whether they would be willing to revise the overview document.

My apology. Rereading your message, I misread it to mean you were asking 
  Mr Powers if they would upgrade (software) since he showed an urgency 
to get an operation going now.  My bad, I read you wrong. Sorry.

--
HLS

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Mar 2007 13:23:41 +0000

Hallam-Baker, Phillip wrote:

> It is sufficient to have last call on the policy requirements. 

Well, it would be if we got some last-call comments.

Can I ask folks to read ssp-reqs and send their comments please.

Stephen.

---

From: Tony Hansen <[email-masked]>
Date: Sun, 18 Mar 2007 19:21:37 -0400

Eliot Lear wrote:
> The real question for me now is simply this: will those people who
> are writing the overview now commit to updating it after SSP is
> complete? And I for one want to see SSP complete quickly.

Irrespective of whether we publish something now or not, the authors of
the overview document have always been committed to publishing a version
that includes SSP information *at the same time as the SSP protocol
specification*. From the charter:

	Nov 2007	WG last call on SSP protocol
	Nov 2007	WG last call on overview document

What we've been exploring in this little debate here is whether we
should publish a version earlier without much SSP information in it.

	Tony Hansen
	[email-masked]