Subject: [ietf-dkim] A proposal for restructuring SSP

From: Jim Fenton <[email-masked]>
Date: Fri, 25 Jan 2008 16:03:07 -0800

Eric Allman and I have been discussing a larger change to the SSP 
specification that we believe addresses a number of the issues that have 
been raised.

The biggest change is the separation of the SSP function into a 
"checker", that retrieves the SSP record/records relevant to a given 
message, and provides this information to an "adjudicator" that makes 
the ultimate decision on how the message should be processed at a given 
site.  The Adjudicator combines the DKIM signature information, SSP 
Checker results, and any other information it cares to consult (possibly 
including, but not limited to, reputation, accreditation, content 
filtering, SPF, and Sender ID).  The definition of the Adjudicator is 
out of scope of the SSP specification.

This version addresses concerns expressed in several issues:

   o  Reworded introduction for clarity.

   o  Added definition of Signing Identity and other definition
      clarifications.

   o  Made examples of "strict" practice use non-normative (partially
      addresses issue 1538).

   o  Clarified possible confusion over handling of syntax errors.

   o  Removed normative language from Introduction (issue 1538).

   o  Changed "Originator" to "Author" throughout (issue 1529).

   o  Removed all references to Third-Party Signatures (issues 1512,
      1521).

   o  Removed all mention of "Suspicious" (issues 1528, 1530).

   o  Removed "t=y" (testing) flag (issue 1540).

   o  Broke up the "Sender Signing Practices Check Procedure" into two
      algorithms:  fetching the SSP record and interpretation thereof
      (issues 1531, 1535; partially addresses issue 1520).

   o  Document restructuring for better flow and remove redundancies
      (some may address issue 1523, but I'm not sure I understand that
      issue completely; also issues 1532, 1537).

   o  Removed all mention of how this interacts with users, even though
      it makes parts of the document harder to understand (issue 1526).

   o  Introduced the concepts of "SSP Checker" and "Adjudicator".

This draft isn't ready for submission yet, but I wanted to provide an 
indication of the direction of the editors' thinking, and get a general 
reaction if this is going in the right direction.  I'm hoping NOT to 
launch another multi-zillion-message thread with this message, so please 
keep your comments at a high level for now until (assuming there is 
general consensus to go in this direction) this is submitted.

-Jim

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 25 Jan 2008 17:19:52 -0800

At 4:03 PM -0800 1/25/08, Jim Fenton wrote:
>specification that we believe addresses a number of the issues that 
>have been raised.
>
>message, and provides this information to an "adjudicator" that 
>makes the ultimate decision on how the message should be processed 
>at a given site.  The Adjudicator combines the DKIM signature 
>information, SSP Checker results, and any other information it cares 
>to consult (possibly including, but not limited to, reputation, 
>accreditation, content filtering, SPF, and Sender ID).  The 
>definition of the Adjudicator is out of scope of the SSP 
>specification.

That could indeed bring the various parties into agreement. Maybe we 
(for some more inclusive value of "we") will find Peace In Our Time.

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 26 Jan 2008 11:39:17 +0100

Jim Fenton wrote:
 
> The definition of the Adjudicator is out of scope of the SSP
> specification.

If an "adjudicator" decides to reject mail RFC 4408 (+ errata)
propose corresponding SMTP reply and enhanced status codes.

Maybe SSP can also offer this, "roll your own" is a bad idea.

> o  Changed "Originator" to "Author" throughout (issue 1529).

Thanks.

> o  Removed "t=y" (testing) flag (issue 1540).

Good.

> o  Introduced the concepts of "SSP Checker" and "Adjudicator".

Fine, roughly what RFC 4408 has as "checkhost algorithm" spitting
out a result, what receivers (~ adjudicators) do with the result
is in essence their business.

 Frank

---

From: Hector Santos <[email-masked]>
Date: Sat, 26 Jan 2008 11:32:58 -0500

Jim,

If this proposal does not provide the fundamental standard idea of 
checking for DKIM signing protocol consistency, then I don't think this 
is solving the basis issue here.

If we separate this fundamental SSP checking concept into a separate but 
"out of scope" adjudicator "plug and play" idea, where one segment uses 
this, another uses that, etc, then I think this will create an 
exploitable situation of target hot spots.  This idea is one the Cat's 
Meow in the Bad Actor World.  As long as they know there will be a 
population of similar systems, but some are weaker than others, they 
will continue to target everyone with the hope of hitting the weaker 
ones.  That means a DOMAIN is vulnerable in varying DKIM systems.  I 
don't think we want this to happen.

Unless I am missing something,  this new separation and complexity 
provide no world wide standardization for general case, widely adopted 
expectations by the domain owners.  While is it conceivable the domains 
might not care how a receiver reaches a decision, I believe they will 
care that the end result is consistently the same across the board, at 
least from a standards point of view.

In my technical opinion,  this "Roll your own" filtering is going to 
create hot spots of target systems and lower the confidence of DKIM 
signers. We would be offering a "cross your fingers" approach with a 
lack of confidence of how a receiver is expected to operate.

IMV, restrictive policies needs to be available for DKIM signers with a 
expectation they will be honored across all SSP supportive systems 
regardless of what add-on adjudicators are available.  We will not be 
able to do this with a 3rd reputation service dependency.

-- 
Sincerely

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

---

From: Jim Fenton <[email-masked]>
Date: Sat, 26 Jan 2008 17:26:27 -0800

Hector Santos wrote:
> checking for DKIM signing protocol consistency, then I don't think 
> this is solving the basis issue here.
>
> If we separate this fundamental SSP checking concept into a separate 
> but "out of scope" adjudicator "plug and play" idea, where one segment 
> uses this, another uses that, etc, then I think this will create an 

There is variability in any case, because some recipients will not 
deploy DKIM at all, and others will deploy it without SSP.  Others will 
deploy something SSP-like, even if SSP is very specific about how things 
should be done.
> expectations by the domain owners.  While is it conceivable the 
> domains might not care how a receiver reaches a decision, I believe 
> they will care that the end result is consistently the same across the 
> board, at least from a standards point of view.

Domain owners have no reason to expect their mail to be handled in any 
particular way.  They can state what they do, IMO they can state 
something about how they'd like their mail handled, but expectations...no.

> lack of confidence of how a receiver is expected to operate.

It's cross-your-fingers anyway, regardless of what the spec says.
>
> IMV, restrictive policies needs to be available for DKIM signers with 
> a expectation they will be honored across all SSP supportive systems 

I agree that we need to avoid a dependency on reputation services, but I 
do believe that reputation services, when available, are useful.  
Unfortunately the current draft is perceived as closing the door to the 
use of reputation and accreditation.  That was not my intent, at least.

-Jim

---

From: <[email-masked]>
Date: Sat, 26 Jan 2008 21:27:49 -0500

I will state <LOUDLY> that without the ability to handle 3rd party signing statements, SSP is useless to me.</LOUDLY>
thanks,
Bill

-----Original Message-----
From: [email-masked] on behalf of Jim Fenton
Sent: Fri 1/25/2008 7:03 PM
To: IETF DKIM WG
Subject: [ietf-dkim] A proposal for restructuring SSP

-Jim

---

From: John Levine <[email-masked]>
Date: 27 Jan 2008 02:46:47 -0000

>I will state <LOUDLY> that without the ability to handle 3rd party
>signing statements, SSP is useless to me.</LOUDLY>

You know that hasn't been in any of the drafts, don't you?

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Sat, 26 Jan 2008 23:44:23 -0800

> I will state <LOUDLY> that without the ability to handle 3rd party signing statements, SSP is useless to me.</LOUDLY>

Can you clarify what you mean by "3rd party signing statements"?  Normal 
volume level is fine.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Sun, 27 Jan 2008 03:32:07 -0500

Jim,

Well, I had much to say, but I'm still in shock by all this.

I just don't get it. Is this idea even allowed in IETF RFCs?  An IETF 
open standard-track proposal requiring a non-standard business solution 
in order to function?

I mean, its not like we have today with an open standard SSL 
client/server system where we have tons of commercial CA vendors and the 
idea is acceptable because they all work with an open standard.  People 
can go from one vendor to another.

We just don't have this with reputation and I don't wish to get holding 
the bag when we burn in some specific trust system proprietary solution 
and they go out of business, change their business model or subscription 
model, or is found to be problematic and exploitable because it isn't a 
standard and hasn't been through a IETF WG vetting process.

My company been there before and don't wish to be getting again of a 
costly revamping of a product line and having PR issues because our 
customers were having a hard time with some reputation service thus 
making their new DKIM system useless.

At the very least, there should be some default consistency with all 
DKIM/SSP compliant systems.

-- 
Sincerely

Hector Santos, CTO

---

From: Eliot Lear <[email-masked]>
Date: Sun, 27 Jan 2008 09:42:00 +0100

Hector Santos wrote:
> open standard-track proposal requiring a non-standard business 
> solution in order to function?

While it may seem suboptimal, this is reality for mail systems today.  
They do all sorts of things that are non-standard to get mail out the 
door.  And it happens in other areas, like NETCONF where the data model 
isn't standard.  In practice you can't manage a system with SNMP without 
enterprise MIBs...

Eliot

---

From: Hector Santos <[email-masked]>
Date: Sun, 27 Jan 2008 04:10:06 -0500

>> Hector Santos wrote:
 >>
 >> I just don't get it. Is this idea even allowed in IETF RFCs?
 >> An IETF open standard-track proposal requiring a
 >> non-standard business solution in order to function?

 > Eliot Responded:

 > While it may seem suboptimal, this is reality for mail systems
 > today. They do all sorts of things that are non-standard to get
 > mail out the door. And it happens in other areas, like NETCONF
 > where the data model isn't standard.  In practice you can't
 > manage a system with SNMP without enterprise MIBs...

Eliot,

I was referring to interface points or system interfacing. While
the back end data may be proprietary in some particular protocol, the 
system interface typically must be a standard in order to be useful.

We don't have standard interfacing with reputation systems.

Furthermore, I find it problematic from a stragetic business and
product development standpoint that we will be stuck with little
choices in this area and quite frankly, the potential is really
high that the current vendors may not be around in the future
and/or alter their own business model that it breaks current
operations.

Again, we been there before with this "batteries required"
concept and it was a costly situation for us when we designed a
product around a non-standard interface solution and the 3rd
party vendor was non-responsive to customer concerns and support
issues and eventually they went out of the business.

That said, what are the reputation "Adjudication" hooks that SMTP
vendors will be able to choose from and offer to customers?

--
Sincerely

Hector Santos, CTO

---

From: <[email-masked]>
Date: Sun, 27 Jan 2008 09:33:39 -0500

Yes, which is why I stopped following the mailing list closely until I realized that some folks presented Ideas even more harmful to my business model. Jim's post that I was responding to did mention 3rd party, negatively, so I was once again trying to bring to the attention of everyone that without third party signing large ISP's have zero interest in DKIM signing or SSP. 
thanks,
Bill

-----Original Message-----
From: John Levine [mailto:[email-masked]]
Sent: Sat 1/26/2008 9:46 PM
To: [email-masked]; Oxley, Bill (CCI-Atlanta)
Subject: Re: [ietf-dkim] A proposal for restructuring SSP

R's,
John

---

From: <[email-masked]>
Date: Sun, 27 Jan 2008 09:47:46 -0500

For SSP to have any value, I need to have the ability to handle the following scenario

joebob.org SSP = isp.foo.com is my signing entity
isp.foo.com SSP = I sign 3rd party mail http://foo.com/list_of_entities_I_sign_for

without a way of stating that I wont be able to serve a million business customers who have no clue on how to manage DNS or do DKIM which rather slows adoption rates. Without this the only people doing DKIM will be the spammers (most of my currently signed mail is from spammers) and large phished entities like paypal. Now since I have a speaking relationship with paypal I dont need to use SSP for them. 
thanks,
Bill

-----Original Message-----
From: Jim Fenton [mailto:[email-masked]]
Sent: Sun 1/27/2008 2:44 AM
To: Oxley, Bill (CCI-Atlanta)
Cc: [email-masked]
Subject: Re: [ietf-dkim] A proposal for restructuring SSP

-Jim

---

From: [email-masked] (Wietse Venema)
Date: Sun, 27 Jan 2008 11:09:42 -0500 (EST)

[email-masked]:
> business customers who have no clue on how to manage DNS or do
> DKIM which rather slows adoption rates. Without this the only
> people doing DKIM will be the spammers (most of my currently signed
> mail is from spammers) and large phished entities like paypal.
> Now since I have a speaking relationship with paypal I dont need
> to use SSP for them.

Bill, 

While time leaks away in disgreements on even simple things, may
I show an example how one DKIM private key could be used to provide
valid first-party signatures for multiple domains.

- Implement DNS DKIM records as CNAMEs to records that are shared
  by multiple domains, instead of giving each domain its own.  You
  could share the same record with all domains, but don't have to.

- Store the private key's NAME in the n= field of the real DKIM
  records, so the signing software can figure out which private key
  to use.  Or find some other way to clue in the signing software.

- Sign with d=customerdomain, instead of d=providerdomain.

By signing with a first-party signature, the verifier's job simplifies
greatly. But doing so also isolates that domain's DKIM reputation
from the DKIM reputations of other domains, for better or worse.

	Wietse

---

From: Michael Thomas <[email-masked]>
Date: Sun, 27 Jan 2008 09:22:14 -0800

>   could share the same record with all domains, but don't have to.

This seems pretty reasonable, and I just looked up for a couple of
DNS providers and it seems that using CNAME's is pretty easy --
surely no more difficult than setting the MX record. If the same
provider runs their DNS and mail, they could easily set it up for
their customers which would be easiest of all.

       Mike

---

From: John Levine <[email-masked]>
Date: 27 Jan 2008 19:26:06 -0000

>isp.foo.com SSP = I sign 3rd party mail
>http://foo.com/list_of_entities_I_sign_for

This strikes me as a situation where DKIM works fine on its own.
DKIM doesn't require any prearrangements.  You just sign the mail.

You set your MTAs to sign the mail going out.  It arrives other
places, and they say aha, it's from Cox, they're OK so I'll treat it
favorably, without having to worry about who's on the From line.  (Or
they might say, it's from Cox, they stink, but there's not much you
can do about that.)  Assuming that people believe that Cox's mail
system is well run, your signature is all they need to link the mail
with you.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Sun, 27 Jan 2008 11:51:40 -0800

The general case of this, "designated signing domains", was considered 
and rejected about a year ago during the SSP requirements process (issue 
#1360).

-Jim

---

From: Damon <[email-masked]>
Date: Mon, 28 Jan 2008 00:00:38 -0500

> system is well run, your signature is all they need to link the mail

Pipe-dream. I am flabbergasted. Bad people sign up for accounts
everyday and in this case, they would get to generate signed mail
until they get shut down. How is this any different than how things
are today? I would dare say it might even get worse. It says to me- I
can't trust the signature. This does absolutely zero in helping to
trust a domain. Not only that, all of a sudden we have reputation
batteries required again. Even if the system is well run, which I am
sure that it is, as is mine, the idea put forth that this is somehow
tied to reputation is ludicrous. Bill, from now on, if you have a
spammer who gets an account, I am going to hold you and your entire
ISP responsible... I know you did it, I have your signature right
here.

Regards,
Damon Sauer

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 28 Jan 2008 12:03:10 -0000

> something about how they'd like their mail handled, but  

SSP is a mechanism for enabling domain owners to express their  
expectations.

AIUI, the proposed "checker" will interpret those "expectations" in the  
context of the particular message with its particular combination of  
signatures, From addresses, Sender addresses and whatever else, and pass  
its interpretation on to the "adjudicator". Essentially, the description  
of the "checker" in the draft will be just the way of expressing clearly  
the "semantics" of SSP.

What the adjudicator then does is out of scope (our scope is to ensure  
that he is in no doubt about the domain owner's expectations).

I.e. it is perfectly in order for a standard to speciffy the methods  
whereby a horse may be led to water - but no further.

-- 
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: <[email-masked]>
Date: Mon, 28 Jan 2008 10:01:17 -0500

"Bill, from now on, if you have a
spammer who gets an account, I am going to hold you and your entire
ISP responsible... I know you did it, I have your signature right
here."
Would you care for a list of largish mail systems/ISP's that do that
now?

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: Damon [mailto:[email-masked]] 
Sent: Monday, January 28, 2008 12:01 AM
To: John Levine
Cc: [email-masked]; Oxley, Bill (CCI-Atlanta)
Subject: Re: [ietf-dkim] A proposal for restructuring SSP

Regards,
Damon Sauer

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 28 Jan 2008 10:18:22 -0500

I'd like to voice my support for Bill's position, notwithstanding #1360
from a year ago. 

The reality is that many smaller domain owners rely on their ISP or some
other service provider to deal with the "under-the-hood" stuff. The
cname suggestion is interesting but I  haven't had time to think it
through. 

Bill and anybody else who is responsible for outbound mail knows that
they are going to get dinged - signed or not - if they don't address
issues caused by mail coming from their system.

If Bill is willing to sign and wants a stronger statement made by SSP
that the domain uses his DKIM signature, where is the technical
objection? It indicates the From domains signing policy and makes it
easier for a receiver to more clearly ascertain a party that wants to
take responsibility for the message. Isn't that the object of the
exercise?

Mike

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of [email-masked]
>Sent: Monday, January 28, 2008 10:01 AM
>To: [email-masked]; [email-masked]
>Subject: RE: [ietf-dkim] A proposal for restructuring SSP
>
>spammer who gets an account, I am going to hold you and your 
>entire ISP responsible... I know you did it, I have your 
>signature right here."
>Would you care for a list of largish mail systems/ISP's that 
>do that now?
>
>
>

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 28 Jan 2008 10:32:22 -0500

> cname suggestion is interesting but I  haven't had time to think it

I've done this with some customers.  As long as:

1.  Their DNS provider supports it.

2.  They don't mess it up.

it works fine.

>From my limited experience, most DNS providers support TXT now, but the 
underscore is often problematic.  I've had more than one problem with "Not a 
valid hostname" errors.  Of course that's correct, but misses the point that 
not all domain names are host names.  I expect that in time this will change.

The biggest problem is getting non-technical domain owners to correctly 
publish the CNAME.

Scott K

---

From: <[email-masked]>
Date: Mon, 28 Jan 2008 10:47:06 -0500

Actually my customers usually have an IP that is within my domain. So if foo.com signs without an SSP statement, software could determine that joebob.com belongs to that IP range set that foo.com owns. In that case resposibility for the message is set.
thanks,
Bill

-----Original Message-----
From: MH Michael Hammer (5304) [mailto:[email-masked]]
Sent: Mon 1/28/2008 10:18 AM
To: Oxley, Bill (CCI-Atlanta)
Cc: [email-masked]
Subject: RE: [ietf-dkim] A proposal for restructuring SSP

Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 28 Jan 2008 08:34:56 -0800

> issues caused by mail coming from their system.

That's why DKIM was made flexible enough to let a variety of different domain 
names be used for signing.  In this case by the Operator.

Except possibly in tightly integrated scenarios, there is no need to tie the 
signature to the From: field, when the signature is not being performed by the 
author.  The operators reputation will suffice.

Keep in mind that all of this mechanism is for filtering engines, not end user 
display.

> objection? 

My own reading of Bill's reqest is that it adds significant complexity to the 
specification and therefore to the implementation and therefore to the 
interoperability challenge.  Perhaps I've misunderstood his request, but as 
noted, it appears to be something that really was discussed at length by the 
working group and rejected because DNS delegation covers the requirement, 
without adding complexity to SSP.

d/

-- 

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

---

From: "Siegel, Ellen" <[email-masked]>
Date: Mon, 28 Jan 2008 11:41:12 -0500

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Scott Kitterman
> Sent: Monday, January 28, 2008 10:32 AM
> To: [email-masked]

Those caveats are pretty significant for a lot of smaller domain owners.
It's not generally the case that DNS providers provide easy-to-use tools
for creating arbitrary authentication-related records. And unless the
tools are *really* good, they won't do much to solve the "they don't
mess it up" part even if they do exist. 

Ellen 

> underscore is often problematic.  I've had more than one problem with
"Not
> a
> valid hostname" errors.  Of course that's correct, but misses the
point
> that

---

From: Hector Santos <[email-masked]>
Date: Mon, 28 Jan 2008 13:04:42 -0500

> You know that hasn't been in any of the drafts, don't you?

I have no idea what you are thinking John, but all the POLICY I-D 
drafts, starting with the original SSP-00, the derivative DSAP, and the 
updated SSP-01, all had information regarding 3rd party signing 
expectations and controls.

Starting with SSP-00, it had the explicit policies:

    o=~  NEUTRAL (signature optional, 3rd party allowed)
    o=-  STRONG  (signature required, 3rd party allowed)
    o=!  EXCLUSIVE (signature required, no 3rd party)
    o=.  NEVER or NOMAIL (no mail expected)
    o=^  USER
    o=?  WEAK (signature optional, no third party, PROPOSED)

Quite often, some of the best ideas are the initial ones!!

With all the discussions, a derivative draft called DSAP was written 
focusing on the security and protocol consistency of DKIM:

    From the viewpoint of the verifier, when a message is received, there
    are two basic pieces of signature information to be of interest when
    analyzing the transaction:

    o  Original Party Signatures (OP)

       *  never expected
       *  always expected
       *  optional

    o  3rd Party Signatures (3P)

       *  never expected
       *  always expected
       *  optional

    When the two signature types are combines, the possible policies are
    listed in this following table:

     +=================================================================+
     | op=         | 3p=        | Domain Policy Semantics              |
     |=================================================================|
     | empty       | empty      | No mail expected                     |
     |-----------------------------------------------------------------|
     | never       | never      | No signing expected                  |
     | never       | always     | Only 3P signing expected             |
     | never       | optional   | Only 3P signing optional             |
     |-----------------------------------------------------------------|
     | always      | never      | OP signature expected                |
     | always      | always     | Both parties expected                |
     | always      | optional   | OP expected, 3P may sign             |
     |-----------------------------------------------------------------|
     | optional    | never      | Only OP signing expected             |
     | optional    | always     | OP expected, 3P expected             |
     | optional    | optional   | Both parties may sign.               |
     +-----------------------------------------------------------------+

These cover all possibilities from what could be expected.

SSP-01 was written and reduced/folded its policies to include:

    DKIM=STRICT

which specifically targets unexpected 3rd party signatures.

-- 
Sincerely

Hector Santos, CTO

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 28 Jan 2008 13:19:17 -0500

On Monday 28 January 2008 11:41, Siegel, Ellen wrote:
> > > I'd like to voice my support for Bill's position, notwithstanding
>
> #1360
>
> > > from a year ago.
> > >

Absolutely.  I've had to send them copy and paste this into your provider's 
U/I type instructions.

Now last I checked Network Solutions didn't even provide TXT, so there's a 
large fraction of the internet that can't do any of this without changing 
providers.

Scott K

---

From: Damon <[email-masked]>
Date: Mon, 28 Jan 2008 13:47:10 -0500

> issues caused by mail coming from their system.

Something that we (us trench warfare guys) have always had to do. But
passing off signing to a third party and not having to be in that
business (unless it's a value add ;-) and not having to sully the
reputation of the ISP as a whole is a far better solution in my eyes.

> that the domain uses his DKIM signature, where is the technical

No objection on my part- but I think we could do better.

>It indicates the From domains signing policy and makes it

Certainly but for largish ISP's and large corporations who do a lot of
farming of their applications, being able to slice it up instead of
getting the whole hog would be preferable and make the entire exercise
worthwhile. I for one would certainly implement a lot faster with this
capability.

Regards,
Damon

---

From: John Levine <[email-masked]>
Date: 28 Jan 2008 19:26:56 -0000

>reputation of the ISP as a whole is a far better solution in my eyes.

Of course.  The ISP doesn't have to sign mail of people they don't
trust, even if they're customers.

As the doctor said to the patient who said "It hurts when I do this",
"Don't do that".

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Jan 2008 11:32:13 -0800

> large fraction of the internet that can't do any of this without changing 

Do they support CNAME? For a small domain, a simple CNAME of their
selector to point to their ESP's selector would be sufficient. I
think I was looking at some help info for google's blogs and they
provide UI explanations on how to point a CNAME at the right thing
for a lot of different DNS providers. This isn't any more rocket
science as creating a MX record, IMO.

		Mike

---

From: <[email-masked]>
Date: Mon, 28 Jan 2008 15:45:27 -0500

OFFLIST,
Checked with the man who would actually do the typing or script writing.
It would be a major project as each domain 200k+ needs an entry pointing
to the shared key. Lot of work at this point so we will wait for the
spec to stabilize, vendors to build a ssp compliant checker then offer
it as an enhanced premium.
 
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wietse Venema
Sent: Sunday, January 27, 2008 11:10 AM
To: [email-masked]
Subject: Re: [ietf-dkim] A proposal for restructuring SSP

Bill, 

	Wietse

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 28 Jan 2008 16:04:49 -0500

> OFFLIST,

or not ...

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Jan 2008 18:13:19 -0800

On Jan 27, 2008, at 8:09 AM, Wietse Venema wrote:

> [email-masked]:
>> business customers who have no clue on how to manage DNS or do DKIM  
>> which rather slows adoption rates. Without this the only people  
>> doing DKIM will be the spammers (most of my currently signed mail  
>> is from spammers) and large phished entities like paypal. Now since  
>> I have a speaking relationship with paypal I dont need to use SSP  
>> for them.
>
> Bill,
>
> While time leaks away in disgreements on even simple things, may I  
> show an example how one DKIM private key could be used to provide  
> By signing with a first-party signature, the verifier's job  
> simplifies greatly. But doing so also isolates that domain's DKIM  
> reputation from the DKIM reputations of other domains, for better or  
> worse.

Although raised as an issue for requirements in:
https://rt.psg.com/index.html?q=1360

Since then, a draft illustrating how SSP could be extended has been  
provided:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-02.txt

CNAMEs pointing to public keys requires an ongoing record co- 
ordination between providers and their customers.  A co-ordination  
that requires specialized signing and their customer's routine re- 
mapping of CNAMEs to the provider's current key locations.  Public key  
locations are expected to change whenever the key itself changes.  DNS  
domain delegation is a similar alternative that places the re-mapping  
process into the hands of a single entity.

CNAMEs or DNS delegation require specific provisions before customers  
can authorize the providers to sign on their behalf.  Specific  
provisions means DKIM public key redirection requires a premium  
service.  The service that includes public key redirection can not be  
managed autonomously.  In addition, email servers and name servers  
might represent an interaction between three different organizations  
managing key records to permit a customer's signature.  Such co- 
ordination will be expensive to manage, and effectively means  
providers will control their customer's private keys.  Private keys  
that "belong" to the customer, but where a customer might never see  
them.  When there is a problem, by redirecting to a provider's public  
key, the domain owner thereby becomes culpable with this dangerous  
transparent authorization.

When an outsourcing provider experiences a breach in security,  
thousands of different domains could become imperilled.  Notification  
of a single breach may require thousands of domains to be listed.   
Those listed would be those domains whose security may have been  
compromised by the exposure of perhaps a single provider's private  
key.  Costs related to managing these transparent key redirect  
authorizations also  precludes scaling the authorization mechanism to  
encompass mailing-lists, for example.

The TPA-SSP alternative does not require the provider's customers hand  
over their private keys or name space.  When there is a security  
breach, only domains whose systems had been compromised need to be  
listed in a security report.  TPA-SSP represents a safe, low cost  
solution for third-party authorizations.

When thousands of a provider's customers are using a common key, the  
provider's servers become high profile targets.  These high profile  
targets can be attacked by exposing the private key, or by  
successfully spoofing the identify of the customer during message  
acceptance.  TPA-SSP does not represent transparent authorization, so  
when there is a problem, the provider would be contacted first.  By  
not having a transparent scheme, any security compromise would be easy  
to report and to resolve.  The authorization itself could be done by  
the customer autonomously, without specific signing provisions being  
established.  TPA-SSP allows DKIM authorization to become a safer low  
cost option for the customer.

When an email authorization scheme is define by providers, their  
desire is to shift culpability and support onto the often hapless  
customer.  Providers must be held responsible for the security of  
their servers, and required to act when abuse is discovered.  The non- 
transparent authorization scheme provided by TPA-SSP ensures a  
culpable domain remains apparent.  Transparent schemes based upon  
CNAME redirection will be expensive to manage, and represents a  
security risk as knowing who to contact is unclear.

DKIM does not identify individuals, nor provides results suitable to  
be directly displayed to the recipient.  There is no reason for third- 
party authorization to be transparent.  In addition, TPA-SSP will not  
increase the amount of overhead when compared against the use of a  
CNAME.  SSP should at least define a flag that indicates when TPA-SSP  
is being used.

-Doug

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 29 Jan 2008 19:24:29 -0500

>propose corresponding SMTP reply and enhanced status codes.

Interesting suggestion Frank. In you mind would this be a 5.7.x
enhanced status code?

-- 
:: Jeff Macdonald | Director of 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: "Frank Ellermann" <[email-masked]>
Date: Wed, 30 Jan 2008 15:34:33 +0100

Jeff Macdonald wrote:
 
> would this be a 5.7.x enhanced status code?

http://tools.ietf.org/html/draft-hansen-4468upd-mailesc-registry
notes that X.7.1 is associated with 550 pointing to RFC 3463 for
the details:

| X.7.1   Delivery not authorized, message refused
| The sender is not authorized to send to the destination.  This
| can be the result of per-host or per-recipient filtering.  This
| memo does not discuss the merits of any such filtering, but
| provides a mechanism to report such.  This is useful only as a
| permanent error.

5.7.0 is apparently too unspecific.  In theory SSP could create
its own 5.7.x if the eight existing codes are not good enough:
http://tools.ietf.org/html/rfc3463#section-3.8

 Frank

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 30 Jan 2008 09:51:39 -0500

>http://tools.ietf.org/html/rfc3463#section-3.8

That is what I'm getting at. A new 5.7.x.