Subject: [ietf-dkim] NEW ISSUE: limiting SSP to statements that inform recipient about (potential) signer actions

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2007 09:00:36 -0800

> 1.  Signer/Validator practices "negotiation" scope
> 
> SSP's description of itself as including "how verifiers should... interpret
> those results" states a scope of protocol semantics that is new to the IETF;
> the protocol is not constrained to "interpret" with respect to defining what
> the published information means, but rather is meant to guide, or even
> mandate, how the mail receive-side participant should handle messages.
> 
> I believe the IETF has not previously standardized a specification which
> attempts to have one network participant dictate the internal operating
> behaviors of another, outside of the protocol interaction itself. As such,
> efforts in this direction need to be careful, modest and incremental.
> 
> There have been some Internet publication mechanisms used that might be
> thought to be similar to SSP.  Most are third-party, centrally controlled
> attribute or quality databases.  These are an entirely different
> administrative and information models from the self-published directive nature
> of SSP. 

To the extent that the above is not sufficiently clear:

    The SSP specification needs to be modified to remove all directions for 
recipient actions, instead limiting itself to statements about the actions of 
a potential signer.

d/
-- 

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

---

From: Arvel Hathcock <[email-masked]>
Date: Sun, 09 Dec 2007 14:38:01 -0600

>    The SSP specification needs to be modified to remove all directions
 > for recipient actions, instead limiting itself to statements about the
 > actions of a potential signer.

This is a manifestation of the thinking that providing guidance to a 
receiver about what you might like to see happen is a violation of some 
Internet taboo.  I just don't see a problem here.

Arvel

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 10 Dec 2007 09:24:13 +0100

Arvel Hathcock wrote:

>> for recipient actions, instead limiting itself to statements about
>> the actions of a potential signer.
 
> receiver about what you might like to see happen is a violation of 
> some Internet taboo.  I just don't see a problem here.

| deny  Messages which are Suspicious from this domain MAY be rejected,
| bounced, or otherwise not delivered at the option of the verifier.
  ^^^^^^^
Trashing suspicious mails ("not delivered") is bad enough, bouncing
them to innocent bystanders is net abuse, unless you have ideally a
PASS or minimally a NEUTRAL indication (no necessarily by RFC 4408).

 Frank

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 Dec 2007 10:36:58 +0100

> some Internet taboo.  I just don't see a problem here.

I'd have to agree.  I thought the point of SSP was for the sender to
provide the receiver on guidance on what it would like done with
messages that are believed to be inauthentic.  While I understand Dave's
concern about organizations communicating policy, if this is a start, so
be it.  It's very constrained.

Eliot

---

From: Hector Santos <[email-masked]>
Date: Mon, 10 Dec 2007 07:46:32 -0500

> be it.  It's very constrained.

The distinction is subtle but SSP is more about a declaration of 
expected DKIM operational behavior.

Its like going to the toy store for x-mas stuff.  All the external 
promotional, advertisement, boxing materials is such that we make that 
purchase with a natural expectation to get what we pay for.

But poor little Billy opens the box and finds that it doesn't contain 
something that was expected.  Our choices are typically clear:

  - Don't worry, tell little Billy its good enough
  - Don't worry, after all its from Toy-R-Us or is it really?
  - Return it, Take it back!

who knows, Sue someone, class action lawsuit!!

The point is, here we want to unleash this new system with DKIM 
signatures and worst, in default neutral and mediocre manner where there 
is a high degree of QA controls lost.

Its all good when the vendors QA is perfect. When it is not, people 
either accept or or do something about it.

A great example of a well known brand name getting exploited:

I have this Toshiba Laptop, a great laptop. I will always pay a little 
more for my stuff at home and at business to get the well known QA and 
support for those "just in case" situations.   The laptop hard drive was 
failing.  Still under warranty, Toshiba support sent me to the nearest 
Certified Toshiba Repair Shop in Miami.

The end result was this:

I expected a 100% Toshiba hard drive replacement. Thats in the Warranty. 
  Something was still not right with it. What was provided was a "fake 
clone" with some internal name of "TosQhiba" or something like that. It 
was not Toshiba product or even a certified manufacturer. It was 
unknown, no web reference, nada.  Calls to Toshiba HQ quickly resolved 
that problem.

So even if we want to put our trust in brand names, even they can be 
exploited and directly receiving material from Certified vendor shops 
(senders) does not guarantee satisfaction.

Most of the times, you have to go to the source to get things resolved.

John Levine's NY Times (Sender), Arvel (From Address) example is another 
example of where we are allow mediocrity to persist.  I would think that 
the NY Times would be very interested to know that somehow, something 
was not right with that transaction.

-- 
Sincerely

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 10 Dec 2007 15:26:21 -0000

> actions of a potential signer.

-1

The specification needs to allow the signer to say what he would *like*  
the verifier to do.

So what SSP currently says is about right (though one might argue over  
specifics, like the role of Sender:). The real problem is the way the  
current draft *describes* thing that are merely advice from the signer to  
the verifier. From that POV, it is a shambles, and until it has been  
rewritten more coherently, we have no chance at all of agreeing upon it.

-- 
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: Damon <[email-masked]>
Date: Mon, 10 Dec 2007 10:51:57 -0500

> CharlesH.Lindsey---------AtHome,doingmyownthing------------------------

+1 on the -1

 I believe that this is an important part of SSP. It gives it sharp
teeth if the implementer so chooses. Something that has always been
lacking and sorely needed on the other specifications that many in
this group, including myself, have hashed out.

Regards,
Damon Sauer

---

From: Jim Fenton <[email-masked]>
Date: Mon, 10 Dec 2007 16:47:01 -0800

[Subject line changed with item number]

> be it.  It's very constrained.

Agree with Eliot and Arvel (disagree with issue 1520).

For those that are looking for a precedent, I'd like to point to RFC
2597 (Assured Forwarding PHB Group) as an example of where there is a
requirement on the recipient, in this case of a packet, to handle it in
a particular way.  From Section 2:  "Within an AF class, a DS node MUST
NOT forward an IP packet with smaller probability..."  In any case, the
SSP draft is nowhere near as normative as this.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Dec 2007 19:18:08 -0800

> SSP draft is nowhere near as normative as this.

Jim,

1.  We seem to be seeing inconsistency between whether SSP is providing 
information about potential signers, versus whether it is directing the 
behavior of receivers.  ("providing guidance" is giving direction.)

2. RFC 2597 specifies actions relative to packets that are from the specifier 
of the actions.  SSP is about messages that the specifier has not issued.

3. RFC 2597 has been at Proposed Standard for 8 years.  Can you point to some 
deployment discussion, so that we can see how broadly it has been deployed and 
how well it works?

d/

-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Mon, 10 Dec 2007 23:06:38 -0800

Dave Crocker wrote:
> 1.  We seem to be seeing inconsistency between whether SSP is
> providing information about potential signers, versus whether it is
> directing the behavior of receivers.  ("providing guidance" is giving
> direction.)
SSP is clearly providing information about the use of DKIM by domains. 
It is also allowing those domains to express their preference about the
handling of mail that purports to come from them.  The intent in this
latter regard is that domains are encouraged to do as requested by the
alleged originating domain, but that they are compliant with the
specification even if they choose not to do so.
>
> 2. RFC 2597 specifies actions relative to packets that are from the
> specifier of the actions.  SSP is about messages that the specifier
> has not issued.

True, but I consider that just a characteristic of the different use
cases between SSP and Diffserv.
>
>
> 3. RFC 2597 has been at Proposed Standard for 8 years.  Can you point
> to some deployment discussion, so that we can see how broadly it has
> been deployed and how well it works?

The point is that RFC 2597 is an IETF standards-track document, and an
example of a protocol which seeks to direct the behavior of receivers
(to use your terminology).  It does this with considerably more forceful
language than the SSP draft currently uses.

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Dec 2007 11:45:46 +0000

I would think that probably the l*vpn and IPsec specs might be
better precedents for telling receivers to drop packets not
from the expected source.

However, in those cases, the attacks are probably less likely
to occur (compared to the SSP case) and the amount of legitimate
traffic that'd arrive at the receiver accidentally is probably
also less that in the case with SSP. However, the relative
similarities are probably debatable.

So, there're some precedents, but of course no exact match and
hence we get to decide what we want to do (and after that the
broader IETF community get to say what they think about it).

In the end, I think "unprecedented" is really a caution
that we should sit back and think before we do whatever we
do, but should not represent a barrier to doing something new,
if that's what we think is needed.

The question of how strongly or weakly to describe the sender's
actions/wishes is IMO a separable one, so I don't think we should
be that caught up with the nitty-gritty of specific possible
precedents here.

S.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 11 Dec 2007 06:51:26 -0800

On Dec 10, 2007, at 11:06 PM, Jim Fenton wrote:

>> directing the behavior of receivers.  ("providing guidance" is
>> giving direction.)
>

Agreed.

> It is also allowing those domains to express their preference about  
> the handling of mail that purports to come from them.

"Purporting to come from" is not defined by SSP or DKIM.

"Purporting to have been authored by a user of the domain" is how SSP  
is currently limited.

Defining which messages can be initially "authored" by uses of a  
particular domain disallows fairly normal and perhaps legitimate  
actions by others.  Hence, specific handling statements will break  
normal and legitimate uses of email.  Controlling the handling of  
messages initially "authored" by a particular domain is new.   
Dictating the handling of these messages is unable to consider all  
possible conditions.  Err on the side of caution.  Provide information  
without dictating specific handling.

DKIM requires fewer exceptions.  Fewer exceptions should provide a  
better outcome.  Nevertheless, an SSP specification will be able to  
dictate how email should be handled in _every_ possible case.

> The intent in this latter regard is that domains are encouraged to  
> do as requested by the alleged originating domain, but that they are  
> compliant with the specification even if they choose not to do so.

Any simple handling assertion will be wrong "some of the time" and  
will affect legitimate messages.  DKIM specifications should expect  
that signatures and assertions provide receivers a means to  
"recognize" potentially illegitimate actions.  Let receivers decide  
about handling.

+1520.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Dec 2007 06:54:12 -0800

> I would think that probably the l*vpn and IPsec specs might be

What are the documents and what are the sections in them you refer to?

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Dec 2007 07:03:38 -0800

> What are the documents and what are the sections in them you refer to?

Please don't. Dave's original statement is what needs backing, not some
endless Goldilocks cycle that takes us very far afield from SSP.

	Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Dec 2007 07:01:56 -0800

> specification even if they choose not to do so.

Jim, you might want to review various postings about this.  Please note 
postings from your colleagues who seem to disagree with your position, since 
they are claiming that SSP is merely providing information and they take 
exception to characterizations that it seeks to direct actions.  ("Expressing 
preference about the handling" sounds nicely distant, but it is seeking to 
direct actions.)

> cases between SSP and Diffserv.

Please point to the relevant diffserv text, so we can compare the details.

> The point is that RFC 2597 is an IETF standards-track document,

Sorry I wasn't clear.  I was not trying to ask about legal precedents.  I was 
trying to ask about demonstrated success scenarios.

Lots of IETF protocols fail.  Although the fact that the IETF has put 
something forward might be interesting, but it does not prove anything about 
utility.

  and an
> language than the SSP draft currently uses.

When you point to the relevant language, we can evaluate just how similar its 
assumption, models, and directives are.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Dec 2007 07:05:23 -0800

> I would think that probably the l*vpn and IPsec specs might be

Since you are puting these out as providing satisfactory examples, please 
point to the relevant passages, so we can compare these in terms of 
assumptions, models and directives.  In addition, what are their adoption 
levels and what kind of user populations employ them?

> if that's what we think is needed.

It does if you want a successful protocol.

The less experience there is with a paradigm, the more risk is taken on.

d/
-- 

   Dave Crocker