Subject: [ietf-dkim] ADSP -> Experimental

From: John Levine <[email-masked]>
Date: 10 Mar 2009 01:27:25 -0000

I've been trying to find _adsp records, and there's precious few of
them.  Of the 73 domains that have sent me DKIM signed mail recently,
three have dkim=unknown, two have dkim=all, and the other 68 have no
ADSP.  The two with dkim=all are both tiny personal domains with only
a single user.  I checked obvious candidates that do sign all their
mail and could be considered phishing targets such as paypal.com,
ebay.com, ag.com, and cisco.com, and found no ADSP.

So the implementation experience is, to put it generously, pretty
sparse.  Between the lack of experience and the serious design
problems that a significant number of people in the DKIM group find in
ADSP, it seems like a very poor candidate for standardization in its
current form.

If it were up to me, I'd forget about it for now, get more experience
with DKIM, and try dropping unsigned mail from places like paypal.com
and ag.com to see how much difference it makes and how many of their
signatures break.  (Since Paypal and AG each send mail from a small
set of easy to identify servers, you can generally look at mail with
broken signatures and tell whether it's real anyway.)  When we have a
better understanding of how people use DKIM, how the various
identities are used, and how signatures break, maybe then we can
consider whether there are self-assertions that would be useful to
receivers.

Since there seems to be a faction that is nonetheless eager to publish
something about ADSP, an Experimental RFC would better reflect the
reality of the situation, since ADSP in its current form really is
just an experiment.

R's,
John
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Mar 2009 22:00:58 -0400

> ebay.com, ag.com, and cisco.com, and found no ADSP.

There is no standard to adopt it.  After SSP was killed, who would the 
waste time again to explore something that really didn't look like the 
authors believed in it?  Many have indicated support once there is a 
draft standard.

But you can't use only your assessment because the API that was out 
there did include have SSP support and there were SSP records out here.

> ADSP, it seems like a very poor candidate for standardization in its

You never had any attention to allow POLICY to be part of DKIM. Never, 
to be frank. From the very beginning, you were throwing stones at POLICY.

> If it were up to me.

It is up to you.  You took SSP and wrote ADSP.

 > I'd forget about it for now, get more experience

And so is DKIM!

This is all shameless nonsense.

It is unfortunate both Eric and Jim Fenton allowed their specification 
to be mangled, crippled and swallowed by non believers of Policy.  At 
least Eric has an excuse (health and there are better things in life 
to do deal with this), but Jim did not.

All this time wasted.  It was predicted when you came out with ADSP 
when it was on record you simply never believed in POLICY. So it was 
quite obvious there was not going to be much championing of this 
document.  Now it finally came to fruition.   You can't work on 
something you don't believe it.

Maybe its time as Eric suggested to move forward with an non-IETF 
POLICY document.  Maybe its time as others outside the WG to move 
forward with their suggestions with a POLICY document.

Is there anyone out who believes in POLICY, can champion, can take 
over this ADSP document and help finish it?

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Mar 2009 09:46:37 +0000

Please stop all this ADSP "good"/ADSP "bad" repetition.

ADSP is finished WGLC and the only thing on our agenda
for it now is pushing it further along the process.

The might, or might not, require some minor change as a
result of the resolution one of the 16 errata for 4871,
however, forgetting ADSP, submitting it as experimental,
making wholesale changes etc. are just not on our agenda.

In this WG we've followed an explicit process of requiring
more support/evidence for late changes, when compared to
early changes. At this point, a substantive change in
the content or direction of ADSP would IMO require its
proponent to go away and produce a lot of evidence that
a very substantial number of WG participants have in
fact changed their opinions. I've seen nothing anywhere
approaching that.

So there is really no need to regurgitate all those old
opinions, it just serves to annoy people.

Stephen.

---

From: John Levine <[email-masked]>
Date: 10 Mar 2009 11:33:01 -0000

>Please stop all this ADSP "good"/ADSP "bad" repetition.

I am specifically proposing that we withdraw it as
standards track and resubmit it as experimental,
because that's what it is.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Mar 2009 11:52:41 +0000

You have suggested that many times. The WG and
the BoFs before it always disagreed. End of story
as far as I'm concerned unless *many* of those
that want it as standards-track now indicate
a change of mind.

Again, please stop. This is unproductive and
totally distracting the WG from progressing
with the 4871 errata,

Stephen.

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Mar 2009 08:06:14 -0400

> because that's what it is.

-1

A better suggestion is to pass the baton to someone else.

Two comments:

First, if this is going to be the case, the IETF should allow a new 
proposal replacement proposal (like SSP) to take its place for 
standards track.  Preferably, handled by someone that believes in it, 
can champion it, is willing to get his teeth pulled and pulled some 
himself.  Foremost, not waste people's time.

Second, DKIM is experiment too.  You said so yourself:

    "When we have a better understanding of how people use DKIM,
     how the various identities are used, and how signatures break,
     maybe then we can consider whether there are self-assertions
     that would be useful to receivers."

Well, it is clear to you that people do not know how DKIM will be 
used.  That is an experiment.  You are questioning the unknown,  how 
the valid, failed signatures and no signatures will not only be 
interpreted but more importantly - tolerated.  A factor you have 
dismissed all these years.

-- 
Sincerely

Hector Santos

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 10 Mar 2009 08:47:48 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of John Levine
> Sent: Tuesday, March 10, 2009 7:33 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] ADSP -> Experimental
> 

So let's talk brass tacks......

1) John asserts that he has difficulty finding many ADSP records. I
agree with him that there are likely not many out there. Given all the
changes that have taken place as it mutated from SSP to ADSP in the
various drafts one would have to be a masochist or a pathfinder (willing
to take arrows in the back) to publish records. 

This does not mean that domains that sign all mail have not been
checking to see how receivers would perceive their mail if an ADSP
record were published.

2) John asserts that ADSP should be withdrawn from standards track and
resubmitted as experimental. The only supporting evidence he has
provided is that ADSP doesn't do anything for him personally. He
therefore considers it broken. By that standard (does it do anything for
John) there are lots of standards that should be converted to
experimental.

For 5 domains I am responsible for and for which I have publicly stated
multiple times over the past year or so that all mail is DKIM signed and
receivers can act on that basis (as if ADSP were stable and we were
publishing), roughly (just under) 500 million signed emails have been
sent. 

I have spoken/worked with various receivers as well as participated in 2
closed betas for feedback loops on signing in examining the outcomes
associated with asserting all mail is signed/publishing ADSP. I am aware
of a number of major financial institutions subject to phishing abuse
that have been testing DKIM/ADSP for both outbound and inbound. There
are currently efforts to put together data for the various cases of
validation failure in production environments. The goal being to publish
the data to inform potential implementers of the impacts (positive and
negative) that ADSP implementation might have.

I've stated it before and I'll state it again. ADSP might have been
worked to accommodate the (stated) needs of people like John. The
consensus of the working group was to narrow it down to first party
(author) signing domains. For first party (author) signing domains it
does what it claims to do as far as my experience stated above shows.

It is inappropriate for John to suggest that ADSP should be reclassified
as experimental simply on the basis that it does not benefit him
personally.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 10 Mar 2009 06:34:44 -0700

Stephen Farrell wrote:
> the BoFs before it always disagreed. 
...
> totally distracting the WG from progressing

+1

d/
-- 

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Mar 2009 10:52:55 -0700

On Mar 10, 2009, at 4:52 AM, Stephen Farrell wrote:

>
> You have suggested that many times. The WG and the BoFs before it  
> always disagreed. End of story as far as I'm concerned unless *many*  
> of those that want it as standards-track now indicate a change of  
> mind.

Stephen,

Unfortunately, issues related to ADSP are not independent of DKIM.  To  
encompass typical use, ADSP might require two separate signatures.

While ADSP could solve a problem for a fractional percentage of  
domains,  by providing a low level of suitability, it becomes  
difficult to justify resources to support a few domains.  This is  
especially true in a time when resources are being reduced.  DKIM  
indicates the signing domain is authoritative for its signed  
namespace.   This authority should include signed header fields.  ADSP  
should not limit what signatures are in compliance.  DKIM alone should  
determine DKIM signature compliance!

Progress should not be measured by meeting WG schedules, it should  
also encompass whether WG product meets the goals of its charter.   
Dave Crocker's errata declares signing domains to be opaque, however  
this approach is not supported by the DKIM charter.  DKIM indicates  
the signing domain is authoritative for its signed namespace.  While  
the i= value may not match against any header field, and may not  
represent a valid email-address, it should mean something when it does  
match against an email-address within a signed header field.   
Otherwise, DKIM becomes a fairly useless token added to messages.

-Doug

---

From: Byung-Hee HWANG <[email-masked]>
Date: Sun, 15 Mar 2009 16:44:33 +0900

> opinions, it just serves to annoy people.

Totally i agree with you. Actually ADSP depends on DKIM signature
specification reexamining now, i think.

-- 
Byung-Hee HWANG, KNU 
∑ WWW: http://izb.knu.ac.kr/~bh/

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 Mar 2009 00:24:03 -0400

> specification reexamining now, i think.

One question I am still wondering about is whether this reexamination 
is justified.  I think the complexity is what it always was:

       Whether or not and how middle ware (3rd parties) deals
       with signed or unsigned mail.

A good example is how a MLS (Mail List Server) is molding how ADSP and 
DKIM should be redefined.  The trouble is that it can be half-baked, 
it may only look at it from one side but not the other side.  A MLS, 
like the one that servers this IETF-DKIM mailing list, is stripping 
any DKIM-signature, resigning all mail distribution.

On the one side, the GOOD side, it may be legitimate to do this.  But 
what about the BAD side, is it going to ignore that?

For example, a domain has a DKIM=ALL policy.  I think that means 
anyone can sign but it must be signed.

On the good side, the DKIM-aware MLS, an inherent data destruction 
middle ware, will strip and resign it. The mail remains signed and it 
is valid too.  Thats good.

On the bad side, someone tries to SPOOF the domain by sending mail to 
list and its not signed.

The question is whether DKIM-aware MLS going to honor the DKIM=ALL and 
reject this spoof or continue with the resigning and distribute the mail?

There is also a presumption the MLS will first validate the original 
signature before it continue with the resign.

We author a MLS too and this is the type design change implementation 
questions I have.  IMV, the DKIM-aware MLS needs to first honor the 
possible ADSP, if any, before it decides to blindly resign all mail.

Crossing all the tees and dotting all the eyes.

-- 
Sincerely

Hector Santos

---

From: Paul Russell <[email-masked]>
Date: Tue, 17 Mar 2009 08:51:00 -0400

On 3/17/2009 12:24 AM, Hector Santos wrote:
> IMV, the DKIM-aware MLS needs to first honor the

I could be mistaken, but I do not recall anyone suggesting that any list
server software should "blindly resign all mail".  Your suggestion should
apply to any DKIM-aware process which accepts, re-signs, and resends or
redirects messages, regardless of whether that mechanism is a list service
or a mail forwarding service.

-- 
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame
[email-masked]