Subject: [ietf-dkim] draft-ietf-dkim-ssp-02.txt and ASP

From: [email-masked] (Wietse Venema)
Date: Fri, 1 Feb 2008 19:04:24 -0500 (EST)

In my opinion, as one of the authors listed on the ASP draft, SSP-02
is close enough in spirit to ASP that I could live with either.

The protocol is extensible. Let's gain experience with this basic
protocol and let experience teach us where extensions will be useful.

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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 01 Feb 2008 16:17:04 -0800

> protocol and let experience teach us where extensions will be useful.

I have to say that I _really_ like discardable... I wish I'd thought of that
in the requirements draft as it really captures the jist of what I was 
trying
to get at.

       Mike

---

From: Hector Santos <[email-masked]>
Date: Fri, 01 Feb 2008 19:32:02 -0500

> protocol and let experience teach us where extensions will be useful.

What experiences are you looking for?  What are your goals? Do you 
really think people want to repeat this process again?

As engineers, I would like to believe that we are still capable of 
having intelligent foresight and know-how of our products and operations 
working; what dangers, the loopholes, the benefits and problem areas and 
what I would venture with almost near certainly many property domain 
owners globably will desire greater protection again forgery.

With this watered down specification,  it has all the markings for 3PS 
exploitations - a clear violation of a domain wanting strict controls.

Unless everyone uses DKIM=DISCARDABLE, the idea that DKIM=ALL will trump 
these 3PS violations is something I think you are wrong about, and thats 
an engineering opinion based on practice - not a wishful guess.

At least SSP-01 allows for the possible of 3rd party signatures. This 
new version intentionally has no insight on 3PS.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Hector Santos <[email-masked]>
Date: Fri, 01 Feb 2008 19:35:19 -0500

Michael Thomas wrote:
> I have to say that I _really_ like discardable... I wish I'd thought of 
> that in the requirements draft as it really captures the jist of what I was 
> trying to get at.

You mean that the careful semantics that we tried to use, in not 
directly saying what we wanted or what was really going to to happen 
with 'suspicious or non-compliant" was a problem?

I see no difference in SSP::DKIM=STRICT or ASP::DKIM=DISCARDABLE, other 
than one was "beating around the bunch" but all verifiers know what was 
the ultimate outcome and this other is being more specific.

This is really all very strange.

-- 
Sincerely

Hector Santos, CTO

---

From: "J D Falk" <[email-masked]>
Date: Fri, 1 Feb 2008 20:22:56 -0500

> new version intentionally has no insight on 3PS.

Did you read why?

---

From: Steve Atkins <[email-masked]>
Date: Fri, 1 Feb 2008 17:28:29 -0800

> is close enough in spirit to ASP that I could live with either.

Yup. I think the ASP draft expresses things with a little more  
clarity, avoiding
confusion by implementors, but the explicit statements by each are  
much the same.

> protocol and let experience teach us where extensions will be useful.

Also it does provide the main things that potential relevant users of  
SSP
have been asking for. And it's simple enough to sign off on and deploy
without another six months of bickering over details.

Cheers,
   Steve

---

From: "J D Falk" <[email-masked]>
Date: Fri, 1 Feb 2008 20:32:30 -0500

> In my opinion, as one of the authors listed on the ASP draft, SSP-02
is
> close enough in spirit to ASP that I could live with either.

As another author, +1.

> protocol and let experience teach us where extensions will be useful.

I think this is the only possible way forward.  Maybe it'll turn out
that Hector and Doug are both right, but we won't know until we try it.
(I seem to recall saying something similar about SPF, long ago -- and
look how much we've learned since then!)

Michael Thomas wrote:

> I have to say that I _really_ like discardable... I wish I'd thought
> of that in the requirements draft as it really captures the jist of
> what I was trying to get at.

Yep, in my opinion that's the breakthrough that makes ASP workable for
the most likely near-term use cases.  It gives the "strict" folks what
they need, without encouraging silly newbie mistakes.

---

From: John Levine <[email-masked]>
Date: 2 Feb 2008 01:58:34 -0000

>is close enough in spirit to ASP that I could live with either.

Same here.  The actual wire protocols that the two drafts define are
almost identical.  I look forward to getting the few remaining nits
polished up and being done.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Fri, 01 Feb 2008 22:05:02 -0500

> look how much we've learned since then!)

And what was learned that was not already stated during the SPF 
development process?   I don't seem to recall your input in the SPF 
groups or in MARID and the same concerns that one may claim today were 
already stated during the WGs discussions.

And the same concerns with SPF, which for me regarding RELAXD 
provisions, that were predictable back them,  I will restated it here 
for this SSP-02 A.K.A ASP,  the same exact issues will occur.

For all intent and purposes:

    ASP::DKIM=UNKNOWN     ----> SPF NEUTRAL
    ASP::DKIM=ALL         ----> SPF SOFTFAIL
    ASP::DKIM=DISCARDABLE ----> SPF FAIL

You guys did absolutely nothing new, and simply reinvented the same 
issues that already preexisted.

If you think ASP::DKIM=ALL will exonerate BULK MAILERS, and HOTELS, 
well, you heard it here,  the failures with ASP:DKIM=ALL will not 
tolerated for long.

As it was already said, the beauty of the SSP=STRICT or ASP=DISCARDABLE, 
the same thing really, is that it was path independent unlike the more 
desirable SPF=FAIL policy, but problematic in multi-hop issues.

With anything less, there is NO benefit.

But at the very least with SSP-00, SSP-01, you had a partial solution 
for 3rd party signers.

By eliminating this, you made the problem worst for DKIM, not better.

-- 
Sincerely

Hector Santos, CTO

---

From: Dave Crocker <[email-masked]>
Date: Sat, 02 Feb 2008 07:21:51 -0800

John Levine wrote:
> almost identical. 

+1

>                    I look forward to getting the few remaining nits

+1

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: Sat, 02 Feb 2008 11:32:52 -0500

>> polished up and being done.

Dave, does this document get a pass on the Threat Analysis?  Because now 
it really needs one.

-- 
Sincerely

Hector Santos, CTO

---

From: Jon Callas <[email-masked]>
Date: Sat, 2 Feb 2008 08:51:30 -0800

>> close enough in spirit to ASP that I could live with either.

Same here. I like them both and I am pretty sure you have to squint to  
see the differences. +1

	Jon

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Sun, 3 Feb 2008 12:57:53 -0500

I've read through ssp-02 once (I need at least a few times to catch the
nuances) and I appreciate the addition of ASP and "discardable". I want
to emphasize that my position regarding domains that wish to take a
strong stance is (and has been) based on what I am seeing with regard to
phishing/other attacks and abused high profile domains.

I do agree with Hector that the options provided appear similar to the
outcome with regard to SPF and ~all. I don't know that I'm as troubled
by that. Domain owners have to make decisions regarding the tradeoffs
between security and the uses to which they allow their domains name and
reputation are put to. 

A few specific comments regarding draft-ietf-dkim-ssp-02.txt:

1)Despite the fact that some may perceive my overall stance as hostile
to 3rd party signatures, I am not. I am only against 3rd party
signatures when they conflict with the assertions of a domain owner and
attempt to represent something other than those expressed wishes. In
that regard, I am less than comfortable with the final sentence of 3.2.
It is my belief that most recipient domains are likely to find not
checking author domain SSP (for discardable) as an invitation to abuse.
I am certain that domain mail administrators choosing to ignore such
assertions will quickly get tired of users contacting them regarding
abusive emails so I am not going to contest the wording.

It may be useful to consider - if not now then at some later point - a
mechanism by which either individual authors (as permitted by the domain
owner) or domains using ASP can indicate specific 3rd parties allowed to
sign on their behalf, whether for the main domain or specific
subdomains. This would provide an additional link in the authentication
chain if you will. I appreciate the concerns of some that this might end
up as quite the furball so I am only pointing it out, not pushing it.
I'm not sure that referencing a web page with a list (as was suggested)
is a viable approach. Perhaps this is the intent for ssp-t-tag-flag
under 3.3 in conjunction with selectors. Such an approach might address
the concerns of ESPs and other potential 3rd party signers.

2) I'm surprised that Dave hasn't commented regarding A.3 and the use of
the phrase "forgeries". I'm still ameniable if we can collectively come
up with a better term for the practice involved.

3) I understand why the "Evaluator" module is considered out of scope
for this document other than referencing it. Is there an intent to come
out with a document with regard to the "Evaluator" module? My reason for
asking is that it may be useful to at least define a standard framework
for expressing "any other data sources it cares to use in order to make
a decision regarding how the message should be processed".

Such a framework would allow for interoperability among and between
modules implementing the "Evaluator" function without explicitly
defining the outcome or process of evaluation. Just a thought and not
something I am personally particularly interested in pushing at this
time.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Sun, 03 Feb 2008 10:19:41 -0800

MH Michael Hammer (5304) wrote:
> the phrase "forgeries".

Since you asked:  My +1 came in two parts.

The second was about looking forward to haggling over the final details.  The 
current exchange is about basic support for core changes.

Best to keep the big picture exchange separate from the smaller details.

By my reading of the list support for the core changes seems quite strong, but 
it's still the weekend.

d/
-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 3 Feb 2008 19:43:46 -0000

>checking author domain SSP (for discardable) as an invitation to

It's hard to see this as saying anything other than that SSP
publishers get to regulate the operation of mailing lists,
send-an-article, etc. run by unrelated third parties.

Even if it's against my internal rules for one of my users to
contribute to a mailing list to which you subscribe, I can't imagine
how I could expect that you enforce my rules against my users.

Or to put it more baldly, it's not mail abuse just because I don't
like it.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 4 Feb 2008 09:50:23 -0500

>-----Original Message-----
>From: John Levine [mailto:[email-masked]] 
>Sent: Sunday, February 03, 2008 2:44 PM
>To: [email-masked]
>Cc: MH Michael Hammer (5304)
>Subject: Re: [ietf-dkim] poison signatures, was draft-ietf-dkim-ssp-02
>

John,

It's not that hard to consider my comment as something other than SSP
publishers regulating mailing lists,send-an-article, etc. 

Your assertion is analogous to blaming the homeowner who retains a
security service (and puts up stickers pointing this out) for the fact
that the person down the street chooses to leave their doors unlocked,
the windows open and keys in the car....and for the fact that homeowner
#2 gets abused as a result. The further outcome is that homeowner #1
gets a discount on their insurance while homeowner #2 likely gets
dropped by their insurer. This is not some poisonous plot on the part of
homeowner #1 to cause homeowner #2 grief and get their insurance
provider to drop coverage. Homeowner #1 has simply raised defenses that
make the burglar less likely to abuse them,reduced risk and thus the
criminal is more likely to abuse homeowner #2. Homeowner #2 has many
options with regard to how they might change their circumstances.

Mailing lists,send-an-article, and other services can operate however
they want. I don't envision SSP publishers in any way regulating how
those services MUST operate. Different service providers may choose
different models of operations as they believe is most appropriate for
their circumstances. Ultimately, receivers - whether organizations or
individuals - get to choose which messages (and from whom) they will
accept or reject. Receivers may take many things into consideration. It
may be that DKIM or SSP never grow to be one of those things - time will
tell.

Note that I did not state that recipient domains would/should take a
particular action based on checking author domain SSP, I only pointed
out that not checking generally, if the information is available, would
be an open invitation to abuse. It may be that receivers generally view
the ietf-dkim list as "good" and allow messages from that list through
regardless of DKIM or anything else. On the other hand some recipient
domains may choose to view email purporting to be from their domain (for
example Mail From) and originating from someone elses server as
bad.....hmmm, wait a second, many organizations already do that without
resorting to DKIM. I have noted some MTAs that reject mail if RFC2822
>From does not match RFC2821 Mail From. I find nothing in the RFCs that
would support or encourage such an approach but I also recognize that if
it works for that domain then that is their perogative.

I would like to point out your CircleID article from June 2004 entitled
"Email Address Forgery"
http://www.circleid.com/posts/email_address_forgery/. In it you claimed
greeting cards as one of the "victims" that would be broken by then
newly proposed validation schemes. At that time, we were unable to take
advantage of those various approaches. We decided to change our approach
so that we could take advantage of those approaches. Nobody regulated or
mandated that we change. We simply felt that these approaches enabled us
to work with others to reduce messaging abuse and have thus embraced
them. You choose to remain skeptical regarding these approaches. That is
your perogative. I remember a time when SSH was newfangled and most
folks used telnet and r commands. There may be some people who admin
boxes using telnet across the open internet... I don't know of any
personally.

>contribute to a mailing list to which you subscribe, I can't 
>imagine how I could expect that you enforce my rules against my users.
>

This leads us to the ugly. There is a difference between
stating,expecting and demanding. 

I'm not commanding you to enforce my rules on your list. You will choose
to do what you wish. Remember King Canute?

I'm not demanding that any receiver reject mail from any source. I'm not
even expecting that all receivers will reject mail purporting to be from
my domains but are not signed - regardless of any statement made in SSP.
Receivers will do what they choose. If ignoring SSP works for a
particular receiver then that is what they will do. If another receiver
chooses to incorporate SSP as one of many things they consider, more
power to them. Some receivers may choose to reject anything purporting
to be from my domains that does not have an authenticated  signature. I
happen to believe that something similar to the homeowner example will
occur.

You are asking me to argue about users when I personally am seeking to
protect originating domains that have no users (other than in direct
support of the domains activities), only role accounts for which
messaging is generated from applications. ssp-02 recognizes that
particular circumstance and addresses it, for which I am appreciative.
Some domains with user accounts may choose to make a strict
assertion/discardable. Others may choose not to. That's the beauty of
choice. We should always remember that the right and ability to make
choices inherently includes the right to make poor ones - whatever your
particular definition of poor happens to be.

>Or to put it more baldly, it's not mail abuse just because I 
>don't like it.
>

I don't care to go too far down this path as it's really a strawman.
Unless you reject the notion of equity interest in a domain name (that
is, a domain name is something that one has property/ownership right in)
then you cannot claim it is simply something that "I don't like".
Whether it is a large company or an individual domain owner, they do
have the right to make statements about the proper (or improper use) of
their name. Your apparent concern is that someone might listen to that
statement.

I personally feel no need to go down the legal/philisophical path on
this because ultimately, the receiver (domain or individual) has the
whip hand. Engage in practices they don't care for - whether you call it
abuse or "I don't like" - and your messages will not go through. It is
really that simple. Nobody is forced to carry anothers traffic and
nobody is forced to accept someone elses messages.

Mike

---

From: "Siegel, Ellen" <[email-masked]>
Date: Mon, 4 Feb 2008 09:59:27 -0500

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of John Levine
> Sent: Friday, February 01, 2008 8:59 PM
> Subject: Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt and ASP
> 

+1, and I also like the additional clarity in both drafts on what's in
and out of scope. 

Ellen

---

From: [email-masked]
Date: Tue, 05 Feb 2008 09:32:21 -0800

> up with a better term for the practice involved.

OK.  Looks like the +1/-1 postings on the basic ASP/SSP changes has stabilized. 
  So maybe it's ok to comment on specifics.

And since this is one specifically queried:

The use of the word 'forgery' in both ASP and the latest SSP drafts do intend to 
refer to unauthorized uses of the domain.  I think the wording of the paragraphs 
might be better -- the drafts use almost the same language -- but at least the 
intent matches the semantics of the word.

Whether any of this will have any effect on any meaningful amount of 'forging' 
is an entirely separate matter and one that I think we have thrashed to death. 
I don't see any benefit in thrashing it past death...

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Feb 2008 03:40:04 -0500

[email-masked] wrote:
> OK.  Looks like the +1/-1 postings on the basic ASP/SSP changes has 
> stabilized.  So maybe it's ok to comment on specifics.
> 
> The use of the word 'forgery' in both ASP and the latest SSP drafts do 
> intend to refer to unauthorized uses of the domain.  I think the wording 
> of the paragraphs might be better -- the drafts use almost the same 
> language -- but at least the intent matches the semantics of the word.
> 
> Whether any of this will have any effect on any meaningful amount of 
> 'forging' is an entirely separate matter and one that I think we have 
> thrashed to death. I don't see any benefit in thrashing it past death...

Dave,

Is it fair to conclude that you no longer feel it is necessary to do a 
Security Threat Analysis?

Unfortunately, I know you are not going to respond, so I want to put in 
the archive records that it was made aware of the new security issues 
introduced in ASP that did not exist in any of the previous I-D SSP 
policy drafts the past two plus years.

These new vulnerabilities in ASP will put DKIM-BASE signers are risk 
with domain reputation harm, put receivers are risk with higher overhead 
issues, and put users in harm with higher degree of mail deception. 
Overall, because of these new issues, I believe DKIM-BASE will have a 
greater barrier of adoption because of ASP.

-- 
Sincerely

Hector Santos, CTO

---

From: [email-masked] (Wietse Venema)
Date: Wed, 6 Feb 2008 07:19:27 -0500 (EST)

> Unfortunately, I know you are not going to respond, so I want to put in 

F.Y.I. Text is being drafted, but you will have to wait until it is ready.

	Wietse