Subject: [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Sep 2013 16:52:02 -0700

Folks,

Barry has agreed to sponsor the enclosed status change.

He would like to see discussion formal request.

(If you've already responded to my /in/formal query earlier today on the 
dmarc@ietf list, please now lodge any formal comments you wish to make 
on either of the two lists here.

d/

-------- Original Message --------
Subject: Request to move RFC 5617 (ADSP) to Historic
Date: Wed, 11 Sep 2013 16:09:14 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Barry Leiba <[email-masked]>,  Pete Resnick 
<[email-masked]>

Folks,

This is a formal request, to have DomainKeys Identified Mail (DKIM)
Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status.

It has garnered almost no deployment and use, in the 4 years since its
advancement to IETF Proposed Standard.

In addition, newer work, DMARC, covers the same general email functional
area and already has garnered quite a bit of deployment and use. Hence
it will clarify things for the marketplace to remove standards status
from the apparently-competing, but actually-useless ADSP specification.

Today I sent a query to the MAAWG Technical committee and the IETF DMARC
mailing lists, to assess support for the status change. Within only a
few hours, I've already seen quite a few +1s, and no -1s.

Thanks.

d/

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Sep 2013 18:15:46 -0700

I also agree with this proposal.  I don't have much to add over the text in
the formal request; it lays out the case based on my experience
implementing DKIM and ADSP in open source.  I can also say that I have
never encountered an operation that actively uses it, including current and
previous employers.

-MSK

On Wed, Sep 11, 2013 at 5:46 PM, Terry Zink <[email-masked]>wrote:

> I agree with this proposal.
>
> -- Terry
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Dave Crocker
> Sent: Wednesday, September 11, 2013 4:52 PM
> To: DKIM IETF WG; Apps Discuss
> Subject: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic
>
> Folks,
>
> dmarc@ietf list, please now lodge any formal comments you wish to make on
> either of the two lists here.
>
> d/
>
>
> To: Barry Leiba <[email-masked]>,  Pete Resnick <
> [email-masked]>
>
> Folks,
>
> This is a formal request, to have DomainKeys Identified Mail (DKIM) Author
> Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status.
>
> area and already has garnered quite a bit of deployment and use. Hence it
> will clarify things for the marketplace to remove standards status from the
> apparently-competing, but actually-useless ADSP specification.
>
> mailing lists, to assess support for the status change. Within only a few
> hours, I've already seen quite a few +1s, and no -1s.
>
> Thanks.
>
>
> d/
>
> --
> Dave Crocker
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Hector Santos <[email-masked]>
Date: Wed, 11 Sep 2013 21:24:37 -0400

This will require a substantial review before any change of status is 
done and should be done as part of WG working on Domain Policies.

There is already substantial work with ADSP and APIs implemented and 
deployed. We continue to get world wide usage of our ADSP zone record 
generator wizard:

    http://www.winserver.com/public/wcadsp

Logs can provided upon request.  Commercial software exist that has it 
deployed -- Ours is one of them.

I would like a study done of all the entire scope of Domain Policy 
support whether its for DKIM, SPF or any other future message 
authentication/authorization protocol.

This will help to address and eliminate the huge redundancy and waste 
of at least 4-5 TXT record DNS calls for each mail transaction.  The 
IETF should review all the related mail protocols; SPF, DKIM, ADSP, 
extensions for ADSP such as ATPS and ASL, we have also VBR and now yet 
another one DMARC as one.

Yet, I don't think DMARC covers what was needed.  It fundamentally 
lacks addressing the #1 issue, #1 desire and #1 problem that plagued 
DKIM with SSP and ADSP -- 3rd party signer controls and policy support.

I am considering to re-introduce DSAP (DKIM Signature Authorization 
Protocol) I-D solution and proposed it to the IETF.

     http://tools.ietf.org/html/draft-santos-dkim-dsap-00

The DSAP protocol covers how to handle receiver actions and authorized 
3rd party signer concepts. It also expects any reputation layer to 
work together in integrated fashion.

--
HLS

---

From: Michael Thomas <[email-masked]>
Date: Wed, 11 Sep 2013 18:41:41 -0700

On 9/11/13 6:15 PM, Murray S. Kucherawy wrote:
> I also agree with this proposal.  I don't have much to add over the text in the formal request; it lays out the case based on my experience 
> implementing DKIM and ADSP in open source.  I can also say that I have never encountered an operation that actively uses it, including current and 
> previous employers.

It doesn't help that ADSP's author actively wanted to subvert it.

As far as I can tell, DMARC is warmed over ADSP with a different set of participants
to claim credit for their original ideas.

Mike

>
> -MSK
>
>
> On Wed, Sep 11, 2013 at 5:46 PM, Terry Zink <[email-masked] <mailto:[email-masked]>> wrote:
>
>     From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Dave Crocker
>     (If you've already responded to my /in/formal query earlier today on the dmarc@ietf list, please now lodge any formal comments you wish to make
>     From: Dave Crocker <[email-masked] <mailto:[email-masked]>>
>     To: Barry Leiba <[email-masked] <mailto:[email-masked]>>,  Pete Resnick <[email-masked]
>     <mailto:[email-masked]>>
>
>     Folks,
>
>     This is a formal request, to have DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status.
>
>     It has garnered almost no deployment and use, in the 4 years since its advancement to IETF Proposed Standard.
>
>     In addition, newer work, DMARC, covers the same general email functional area and already has garnered quite a bit of deployment and use. Hence
>     it will clarify things for the marketplace to remove standards status from the apparently-competing, but actually-useless ADSP specification.
>
>     Today I sent a query to the MAAWG Technical committee and the IETF DMARC mailing lists, to assess support for the status change. Within only a
>     bbiw.net <http://bbiw.net>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2013 01:27:30 -0000

>> Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status.

I'm one of the authors, and I think it's a dandy idea.

Other than a few experiments and one or two impressive misfires, such
as one that bounced innocent bystanders off an IETF mailing list,
nobody's ever used it.

R's,
John

---

From: Tony Hansen <[email-masked]>
Date: Wed, 11 Sep 2013 23:09:47 -0400

This seems like a reasonable step to take.

    Tony Hansen

On 9/11/2013 7:52 PM, Dave Crocker wrote:
> (If you've already responded to my /in/formal query earlier today on
> the dmarc@ietf list, please now lodge any formal comments you wish to
> make on either of the two lists here.
>
> d/
>
>

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 12 Sep 2013 03:18:48 +0000

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Michael Thomas
> Sent: Wednesday, September 11, 2013 9:42 PM
> To: [email-masked]
> Subject: Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617
> (ADSP) to Historic
> 
> > I also agree with this proposal.  I don't have much to add over the
> > text in the formal request; it lays out the case based on my
> > experience implementing DKIM and ADSP in open source.  I can also say
> that I have never encountered an operation that actively uses it, including
> current and previous employers.
> 

You made that assertion when the working group was working on ADSP. I disagreed with John on a number of points at the time but I wouldn't call those differences of opinion an attempt on his part to subvert ADSP. Various folks compromised to get the spec out the door. I think that was perhaps because what happened with the MARID working group was in the back of people's minds. If I had a do-over I might not be so willing to compromise. It's water under the bridge.

> As far as I can tell, DMARC is warmed over ADSP with a different set of
> participants to claim credit for their original ideas.
> 

I think you need to look more closely. Many people realized very quickly that ADSP had significant flaws that made implementation extremely risky for both senders and mailbox providers. There were a number of private efforts to move email authentication forward. DMARC was only one of them. Some of those private efforts were premised on a pay-to-play model. DMARC was premised on creating an open standard that worked instead of a private club. A number of the participants in DMARC.org were also active participants in the ADSP discussions. We all learned from operational experience interacting through private channels. The problems with ADSP and how to move past them were certainly a point of discussion (in all the groups I participated in - how could it not be?). The initial attempts were one-on-one pairs of senders and receivers and it was very quickly realized that a standard way of communicating and reporting was needed. ADSP never had reporting on the radar screen and alig!
 nment with SPF wasn't a factor either. 

I haven't seen any of the DMARC participants thumping their chests seeking credit. I see folks from various organizations that needed to solve a problem and having seen positive results in a closed environment felt that an open solution was better than a closed one. As far as credit, J.D. Falk deserves mention for DMARC even though he didn't live to see it come to fruition. I'd like to think that J.D. is smiling somewhere at how far we have come. And yes, he was an active participant in the DKIM/ADSP effort among his many other anti-spam efforts..

Just a few thoughts. Apologies to anyone offended by ths trip down memory lane.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Sep 2013 21:32:32 -0700

> to claim credit for their original ideas.

I don't understand how these assertions are at all relevant to this 
thread, nor the first at all within IETF participation guidelines.

d/

---

From: Michael Thomas <[email-masked]>
Date: Wed, 11 Sep 2013 22:04:25 -0700

On 9/11/13 9:32 PM, Dave Crocker wrote:
> I don't understand how these assertions are at all relevant to this thread, nor the first at all within IETF participation guidelines.

Ho hum, Dave Crocker threatening to get me kicked off working groups again even
if the sentence doesn't actually make any sense.  It still doesn't alter the fact that
he was against it until he was for it.

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Sep 2013 08:47:39 +0200

Dave,

> make on either of the two lists here.

I agree.  To my knowledge there has not been uptake and realistically
DMARC is meant to correct this.

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Thu, 12 Sep 2013 07:57:54 -0700

On 9/11/13 8:18 PM, MH Michael Hammer (5304) wrote:
>
> I think you need to look more closely. Many people realized very quickly that ADSP had significant flaws that made implementation extremely risky for both senders and mailbox providers. There were a number of private efforts to move email authentication forward. DMARC was only one of them. Some of those private efforts were premised on a pay-to-play model. DMARC was premised on creating an open standard that worked instead of a private club. A number of the participants in DMARC.org were also active participants in the ADSP discussions. We all learned from operational experience interacting through private channels. The problems with ADSP and how to move past them were certainly a point of discussion (in all the groups I participated in - how could it not be?). The initial attempts were one-on-one pairs of senders and receivers and it was very quickly realized that a standard way of communicating and reporting was needed. ADSP never had reporting on the radar screen and al!
 ignment with SPF wasn't a factor either.

The list of things DMARC does that ADSP doesn't in its appendix, is a trip down memory lane
of constraints that were placed on it by the against-it-before-they-were-for it set. True
SPF wasn't ever on its radar -- SPF has its own policy language, so nobody wanted to touch
that. And ARF was progressing at the time as it's own spec, so we weren't completely clueless
about its need. But instead of actually working to make a better spec at the time, we had an
author whose goal was to subvert it, and endless idiotic flamewars about what the actual name
of the draft should be as the main priorities. The really sad thing about this is that they pissed
away 6+ years due to the intrigue.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 12 Sep 2013 12:10:44 -0700

On Thu, Sep 12, 2013 at 7:57 AM, Michael Thomas <[email-masked]> wrote:

> of constraints that were placed on it by the
> against-it-before-they-were-for it set. True

I'm lost.  What's the purpose of this branch of the original thread, other
than venting old frustration and lobbing invective?

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Sep 2013 12:28:34 -0700

On 9/12/2013 12:20 PM, Jim Fenton wrote:
> This might be the right thing to do, but it seems like the more
> appropriate time might be to do this when DMARC becomes standards-track.

1. There is not going to be any change the adoption of ADSP between now 
and then.

2. I don't see any obvious reason for linking them.  The mere fact that 
they are playing in roughly the same sandbox does not provide any 
obvious requirement for fate-sharing that I can see.

3. IF DMARC is never standardized, it still makes sense to deprecate ADSP.

> I will note that vanilla, uncustomized SpamAssassin does implement ADSP,
> so there might be more checking of ADSP records than some realize.  See,
> for example:
>
>   http://wiki.apache.org/spamassassin/Rules/DKIM_ADSP_CUSTOM_MED

There seems to be a pattern that has developed, of demanding that 
failure mean literally no adoption.  It doesn't mean that.  It means 
that it has no community traction.  ADSP more than qualifies on the 
pragmatics of failure.

d/

---

From: Michael Thomas <[email-masked]>
Date: Thu, 12 Sep 2013 12:34:55 -0700

On 9/12/13 12:10 PM, Murray S. Kucherawy wrote:
> On Thu, Sep 12, 2013 at 7:57 AM, Michael Thomas <[email-masked] <mailto:[email-masked]>> wrote:
>
> I'm lost.  What's the purpose of this branch of the original thread, other than venting old frustration and lobbing invective?

That we pissed away 6 years for no good reason.

Mike

---

From: Jim Fenton <[email-masked]>
Date: Thu, 12 Sep 2013 12:20:17 -0700

-Jim

P.S. I owe the DMARC folks a review of the DMARC spec, which I have
begun and already have quite a few questions.  I expect to complete this
within a week.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 12 Sep 2013 13:02:44 -0700

> that it has no community traction.  ADSP more than qualifies on the

This was a response to your statement to Barry and Pete, "It has
garnered almost no deployment and use." If that comment was relevant, so
is a comment that there is, in fact, some deployment.

-Jim

---

From: Barry Leiba <[email-masked]>
Date: Thu, 12 Sep 2013 17:07:45 -0400

I'm a bit late here; sorry: IESG telechat day, so things were very busy.

> participants to claim credit for their original ideas.

Note well:

If anyone has technical comments, data collection, or any other stuff
that's relevant to the ADs' judgment of whether moving ADSP to
Historic status is the right thing, those comments are welcome here.

Comments about the people involved are not welcome, and will not be
tolerated.  On the IETF lists, I will be handing out 30-day
suspensions like travel-size toothpaste at a dentist's office in
response to further comments about who's asking for this, including
assertions of their motives, their qualifications, actions they did in
the past, or whatever.

Discussion of ADSP *ONLY*.  No discussion of DMARC.  No discussion of
people.  No snideness.  Just stop all that.

The only thing I will be considering, as this discussion proceeds and
as I analyze it, is what arguments have been made about ADSP, and
whether or not its spec should be classified as Historic.

Barry, Applications AD

---

From: Hector Santos <[email-masked]>
Date: Thu, 12 Sep 2013 17:29:22 -0400

> that it has no community traction.  ADSP more than qualifies on the

The pragmatics of failure also can include implementations but see 
zero payoff in the field. Pure wasted redundant overhead in DNS calls 
and crypto processing is all that is highly measurable.

In our implementation, DKIM and VBR certainly fits in that category. 
Yet, we did it for its "marketing" value.  ADSP is also implemented 
and deployed.  The payoff measured is still another matter.

Even if ADSP domains have DKIM=DISCARDABLE, its been hard to add logic 
to reject or negatively classify failed DKIM messages.  Yet, you don't 
how sites local policies filters are done.  Sites and even users might 
just apply an ADSP DKIM=DISCARDABLE policy rejection to certain high 
value domains, like PAYPAL.COM but not others.

If Authentication-Results headers are used, what is done locally is a 
matter of local policy.  What is to say the same is not possible with 
DMARC with its p=reject action attribute?  I haven't seen any MUA show 
a different view yet, but I am sure there are some in the field.  Some 
have an icon or indicator but its not always profound.

We have the same issue with 3rd party signing problems with DMARC. 
ADSP has extensions such as TPA, ATPS and ASL that attempts to address 
authorized 3rd party signatures.  There is interest and deployments of 
these extensions.  DMARC will not attempt to address 3rd party 
signatures.  Whats to stop an DMARC extension to emerge which can 
piggy back off the _DMARC record?

-- 
HLS

---

From: Barry Leiba <[email-masked]>
Date: Thu, 12 Sep 2013 17:29:32 -0400

> Historic status is the right thing, those comments are welcome here.
...
> whether or not its spec should be classified as Historic.

I'd like to add that in order to keep the discussion from fragmenting,
I would prefer that all discussion of this happen on
<[email-masked]>.  I will keep watching this list as well, and
will try to consider comments made here, but it'll be easier on
everyone if there aren't separate discussions in two (or more) places.

Thanks,
Barry, Applications AD

---

From: "John Levine" <[email-masked]>
Date: 13 Sep 2013 01:04:31 -0000

>>   http://wiki.apache.org/spamassassin/Rules/DKIM_ADSP_CUSTOM_MED

If you look at the DKIM configuration files, you'll see that the ADSP
usage is almost entirely faked up, via a list of entries for the usual
phish targets (ebay, paypal, etc.) to pretend that they have ADSP
records:

http://svn.apache.org/repos/asf/spamassassin/trunk/rules/60_adsp_override_dkim.cf

This tells us that while dropping unsigned mail purporting to be from
famous phish targets is generally a good idea (something I've always
agreed with), ADSP records in the DNS aren't a useful way to make that
happen.

R's,
John