Subject: Re: [ietf-dkim] When will there be SSP Requirements-01?

From: Douglas Otis <[email-masked]>
Date: Tue, 15 Aug 2006 10:54:28 -0700

On Aug 15, 2006, at 7:36 AM, Scott Kitterman wrote:

> It seems like comments have died down on the -00 draft.  Given the  
> number of
> comments/revisions, is an 01 draft planned so we can review that?

There should be an explicit means to differentiate the Bigbank  
scenario from that described as the DKIM Signer Extended scenario.   
There were several comments supporting an ability of policy for  
making this distinction.  The added definition of DKIM Signer  
Extended could be viewed as representing a flag indicating that the  
 From domain is _not_ the target of a phish and uses common email  
services in conjunction with ensuring all initial messages are in  
compliance with the DKIM policy.

To accommodate suitable language for policy to include an  
authoritative list of designated domains, references to First Party  
Signatures should probably be changed to Designed Domain Signatures  
unless clarifying whether the policy lookup is required.

With the use of nominative language throughout, a reference to  
RFC2019 seems appropriate which is normally a few lines added to the  
Definitions section.

It is important being able to declare a state like DKIM Signer  
Complete or DKIM Signer Extended, it also equally important that not  
declaring these states should be a requirement for policy.  In other  
words, these states should not be implied by some other policy  
assertion related to a different feature.  The ability to designate a  
domain should not be impaired by possible delivery issues.  While  
there can be no guarantee how a verifier handles policy, policy  
should at least be able to accurately express common usage.

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

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 15 Aug 2006 10:36:04 -0400

It seems like comments have died down on the -00 draft.  Given the number of 
comments/revisions, is an 01 draft planned so we can review that?

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 15 Aug 2006 17:37:14 -0400

----- Original Message -----
From: "Scott Kitterman" <[email-masked]>
To: "IETF-DKIM" <[email-masked]>
Sent: Tuesday, August 15, 2006 10:36 AM
Subject: [ietf-dkim] When will there be SSP Requirements-01?

> comments/revisions, is an 01 draft planned so we can review that?

Well, its dangerous the dive into this ocean of mixed exotic fishes without
an active lifeguard around :-)

I would like to see one final one just to clean it up, but I personally
would not like to further waste time on word-smiting, semantics,
"terminologies," etc.

We had over one year of discussion and the lines has been drawn.  It is
already clear to me what the DKIM/SSP protocol model has to be, satisfying
any POLICY framework you wish to choose.

Personally?

I think the requirements docs needs a VERY good section on what 3rd party
signatures mean, how they play a role, or don't and why they might be needed
without OA permission.  This is the critical question a DOMAIN will be
facing - why would I want to allow others to sign without my permission and
if so, can I keep a reasonable high level of confidence in the purpose of
signing in the first place.

The latter seems to be one of the main issues of contention here and has
been since last year.

I started thread last year:

3rd party Signers - Definition/Usage
http://www.imc.org/ietf-mailsig/mail-archive/msg01933.html

This helped draw the fine line among all sides, regarding simplicity vs.
complexity, weak vs. strong, the business potentials, the TCO that might be
required between ISP/ESP and domains and users, and respectively including
among those who understood the issues, those who don't, as well as those who
almost understood and rather err with simplicity, etc.

The problem with the usage cases cited in the req-00 doc is that its too
limited and tries to justify a particular type of policy for a particular
type of industry, which can quickly be debunked when just about anyone can
use these benefits of DKIM/SSP.

The WHO and WHY has no bearing on the verifiers  - regardless of who/why, it
all has to be consistent.

Maybe I am completely wrong, but the bottom line to me is what are technical
capabilities of the protocol as it is currently defined and what are the
possibilities that came come from that - good or bad, meaningful or not.  It
is about being consistent on both ends.

So if we want to go simple with 2-3 policies, fine, but we have to lock it
down and not allow the other possibilities to be used as an threat entry
point.

My take is that we don't have to close any of the possible policies. Let the
domain choose what it wants.

People will quickly see what works or doesn't work.  No one want to lose
mail, no one what's to reject legitimate mail.     But I think we all want
is to stop others from using our domains in unauthorized ways.  If that is
not the goal, then why are we doing this for?

Just keep in mind that DKIM will not be successful if there are not enough
receivers out there supporting DKIM.  We might give them a high payoff
REASON to support it.

Lets also keep in mind that if we do this right, it is highly probably and
possible to see an early DKIM verifier-only market out there first that will
not begin signing themselves until some later point.

Lets also keep in mind that if we do this right, it is highly probably and
possible to see an early DKIM policy declaration only market out there first
that will not begin signing themselves until some later point.  This might
be to just expose the idea the domain does not (currently) sign mail or it
doesn't send mail with certain  domains.

So it is very conceivable to have a SSP only market as the domains begin
their begin their DKIM-BASE migration plans.

To me, this would be a good marketing approach for DKIM/SSP.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 15 Aug 2006 17:38:13 -0400

Doug,

> While there can be no guarantee how a verifier handles policy, policy

+1

I call all this protocol consistency.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 15 Aug 2006 18:18:38 -0700

On Aug 15, 2006, at 2:37 PM, Hector Santos wrote:

> We had over one year of discussion and the lines has been drawn.   
> It is already clear to me what the DKIM/SSP protocol model has to  
> be, satisfying any POLICY framework you wish to choose.

There is still a need to better define what policy is expected to  
provide.  The ability of strict policy at stopping a phish or  
constraining email abuse should not be overstated.  However, policy  
can greatly simplify the administration of authoritative domains for  
the 2822.From address.

This name list association tactic can be extended to also qualify the  
2821.MAIL_FROM and 2821.EHLO.  Using this tactic allows evaluation of  
immediate sources and may prove useful at preventing DKIM related  
abuses.  This tactic does not create significant risks from DoS  
amplification exploits.  Perhaps this follow-on effort could occur in  
ASRG.

In all likelihood, a domain designated as authoritative by policy  
offers greater assurance that the 2822.From address is valid.   
Organizations like DAC could ensure proper procedures are followed by  
certified DKIM signers.  The administrative effort should be rather  
simple.  The certified DKIM provider would ensure the authenticated  
account receives email at an address before allowing its use.  To be  
useful, the email-address domain owner would list the certified  
provider in their designated domain list.  The MUA then annotates  
messages containing an addresses found in their address book signed  
by an authoritative domain.  This seems rather practical.  This  
approach does not require third-party services (batteries) and  
prevents exploits that might take advantage of internationalization.

A signature by a designated domain will likely offer greater  
assurances than one that happens to be within the email-address  
domain.  Unless this domain is designated, there is less assurance  
this domain first validates the use of the 2822.From address.  This  
approach could remove some of the risks associated with parent  
domains.  A designated list can exclude parent domains as being  
authoritative, for example.

> I think the requirements docs needs a VERY good section on what 3rd  
> party signatures mean, how they play a role, or don't and why they  
> might be needed without OA permission.  This is the critical  
> question a DOMAIN will be facing - why would I want to allow others  
> to sign without my permission and if so, can I keep a reasonable  
> high level of confidence in the purpose of signing in the first place.

A policy offering domain designation should not attempt to  
differentiate between whether a domain happens to be within the  
2822.From domain.  Annotation of messages containing recognized  
addresses signed by authoritative domains is the only effective  
method for protecting individuals from fraud, a primary motivation  
for deploying DKIM.  In which case, it really does not matter whether  
a mailing list damaged a signature, or an e-invite was sent using the  
requester's 2822.From address.  These messages will not be annotated  
as "recognized" and can be handled accordingly by the individual.

Although DKIM greatly assists in identifying a phish, this will  
likely best occur through MUA recognition based upon what exists  
within the Address Book.  Even the most strict policy attempting to  
limit valid sources will not be as effective in comparison to a  
recognition strategy.  DKIM used in conjunction with strict policy  
will not abate abuse.  Strict policy will cause expensive support  
issues however.

The use of strict policy should be seen as a stop-gap measure for an  
exigent situation.  Once DKIM becomes more widely deployed, which  
only happens if DKIM policy does not create support issues, then MUAs  
that recognize addresses signed by authoritative domains will greatly  
restore trust in email without causing any significant increase in  
complexity or wrenching changes.  Throw out the concept of 3rd party,  
think designated domain.

> The problem with the usage cases cited in the req-00 doc is that  
> its too limited and tries to justify a particular type of policy  
> for a particular type of industry, which can quickly be debunked  
> when just about anyone can use these benefits of DKIM/SSP.

Scenario 1 and 2 did not allow policy to signal which scenario was  
being used.  Beyond the designated signing domain list, perhaps just  
two additional states might prove useful on an interim basis.

  - An "Only" flag indicating whether only complaint sources are used.
  - An "All" flag indicating all initial messages are signed.

DKIM Signer Complete = "All" + "Only"
DKIM Signer Extended = "All"

The recommended assertion would be neither flag.

> So if we want to go simple with 2-3 policies, fine, but we have to  
> lock it down and not allow the other possibilities to be used as an  
> threat entry point.

Here is where we differ.  Bad actors have already demonstrated an  
ability to implement any authentication and policy relationship.  The  
virtually unlimited pool of domain names versus IP addresses ensures  
DKIM is not a choke point.  Ensuring that support and administrative  
issues are kept to a minimum, allows a cost effective and safe  
recognition of addresses signed by authoritative domains.   
Opportunistic recognition will put an end to most sources of email  
related fraud which is not affected by address internationalization.

> My take is that we don't have to close any of the possible  
> policies. Let the domain choose what it wants.

Agreed.

> People will quickly see what works or doesn't work.  No one want to  
> lose mail, no one what's to reject legitimate mail.  But I think we  
> all want is to stop others from using our domains in unauthorized  
> ways.  If that is not the goal, then why are we doing this for?

Authorization of a domain seems to be somewhat of a parochial view.   
Should a mailing list need authorization from the domain owner of the  
subscribing email-address?  Too many really useful things stop  
working when this view is carried to its ultimate conclusion.  DKIM  
can successfully prevent fraud without taking a view that email  
sources must be authorized.  I would rather take the view that only  
recognized email-addresses signed by a designated domain should be  
annotated as "recognized".  If the domain is not designated as an  
authoritative domain or does not have a good reputation, then don't  
even obtain the keys.  Doing so would leak information.  DKIM is  
powerful, but should be used with caution.

> Just keep in mind that DKIM will not be successful if there are not  
> enough receivers out there supporting DKIM.  We might give them a  
> high payoff REASON to support it.

Having messages marked as "recognized" should be more than enough  
reason.  Better still, this works regardless what the email-address  
of the 2822.From might be.

-Doug