Subject: [ietf-dkim] Are verifiers expected to query SSP on a successful verify?

From: Mark Delany <[email-masked]>
Date: Mon, 31 Jul 2006 15:17:22 +0000

I guess I had been making the assumption that an SSP query is only
necessary on a verification failure. Some of the conversations seem to
suggest that an SSP query will be needed regardless of the success of
the verify. Is that the case at all? The uncommon case? The common
case?

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

---

From: <[email-masked]>
Date: Mon, 31 Jul 2006 11:28:12 -0400

How about checking SSP first to see if they sign at all :-)? 

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mark Delany
Sent: Monday, July 31, 2006 11:17 AM
To: [email-masked]
Subject: [ietf-dkim] Are verifiers expected to query SSP on a
successfulverify?

Mark.

---

From: Mark Delany <[email-masked]>
Date: Mon, 31 Jul 2006 16:28:53 +0000

> How about checking SSP first to see if they sign at all :-)? 

For this conversation I'm treating an unsigned message the same as a
verification failure.

In that light, are you refering to an SSP query when no signature
is found in the email, or prior to even trying to verify?

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 31 Jul 2006 09:38:30 -0700

> the verify. Is that the case at all? The uncommon case? The common

Mark,

This came up during the Montreal meeting.  I, too, had been assuming a nicely
symmetric distinction that used dkim-base for signed message and dkim-ssp for
unsigned ones.

Alas, it was pointed out to me that SSP does indeed have a requirement for a
lookup even when the message is signed.  This is when there is so-called
third-party signing.  (I believe this means when the domain in the rfc2822.From
does not make the DKIM d= domain.)

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: Mon, 31 Jul 2006 11:42:39 -0500

> the verify. Is that the case at all? The uncommon case? The common

Currently, the policy of "I don't send mail" would require an SSP query 
for each message.  That is making less and less sense to me.  Either a 
signature (which covers the From: domain) is there or it's not.  If it's 
there what more could SSP usefully contribute to the process?

-- 
Arvel

---

From: Douglas Otis <[email-masked]>
Date: Mon, 31 Jul 2006 09:47:52 -0700

On Jul 31, 2006, at 8:17 AM, Mark Delany wrote:

> necessary on a verification failure. Some of the conversations seem  
> to suggest that an SSP query will be needed regardless of the  
> success of the verify. Is that the case at all? The uncommon case?  
> The common case?

When the desire is to protect the OA, which I admit starts with a  
dubious premise, then when the signing domain does not match the OA  
domain or there is no signature at all, then would the OA policy be  
checked.  This would tend to exclude policy statements specific to  
what other OA domains are signed.  Rather the policy statement would  
be specific to what other domains sign for the OA which seems to be a  
source of confusion.

-Doug

---

From: <[email-masked]>
Date: Mon, 31 Jul 2006 12:58:56 -0400

Can you taken a look at the DSAP proposal or the link Hector
   provided with the SSP verification Interface Diagram? 
It does appear to flow this question
thanks

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mark Delany
Sent: Monday, July 31, 2006 12:29 PM
To: [email-masked]
Subject: Re: [ietf-dkim] Are verifiers expected to query SSP on
asuccessfulverify?

On Mon, Jul 31, 2006 at 11:28:12AM -0400, [email-masked] allegedly

Mark.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 31 Jul 2006 10:04:53 -0700

On Jul 31, 2006, at 9:42 AM, Arvel Hathcock wrote:

> Currently, the policy of "I don't send mail" would require an SSP  
> query for each message.  That is making less and less sense to me.   
> Either a signature (which covers the From: domain) is there or it's  
> not.  If it's there what more could SSP usefully contribute to the  
> process?

The policy would be checked for the OA domain when there is not a  
valid signature from that domain.  When checking the OA domain  
policy, it could be apparent that this domain never sends mail by  
having an empty designated signing domain list and a flag that  
indicates that non-designated domain are not used.  This would not  
involve any additional transactions than already required.  The  
benefit would be the immediate handling of invalid signatures in this  
case.

-Doug

---

From: Mark Delany <[email-masked]>
Date: Mon, 31 Jul 2006 17:28:16 +0000

> Alas, it was pointed out to me that SSP does indeed have a requirement for a

I thought the requirements have yet to be determined?

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 31 Jul 2006 10:45:10 -0700

> I thought the requirements have yet to be determined?

we've had a spec sitting around for a long time.  i was referring to that.

d/

-- 

  Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 31 Jul 2006 14:33:09 -0400

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 31, 2006 12:38 PM
Subject: Re: [ietf-dkim] Are verifiers expected to query SSP on a
successfulverify?

> does not make the DKIM d= domain.)

Correct.

This requirement (aka need) was discussed since the old mailing list and
carried over to the DKIM threat analysis issues discussions.

But I also indicated there that an initial SSP will also cover other
policies as well.  Overall, it covers the following:

    - No mail expected
    - Signed, but no signing was expected
    - Always Signed expected, but mail was not signed.
    - Signed, but no 3rd party signature was expected.

None of the above requires the overhead of a DKIM signature hash and public
key validation.  Once the above policy assertions are proven, then the
DKIM-BASE calculation can take place.

The above are highly possible in an open-ended domain exploitation
environment:

- Legacy Bad Guys using domains they are not suppose to be using for mail.
That is what we have today.

- New Bad Guy trying to fake a simulation of a domain's DKIM support.  Even
if the signature is invalid, the bad guy hope is that you will ignore this
per DKIM-BASE specification and just pass on the message to the next layer,
if any.  SSP does not eliminate all fake simulation, only the most obvious,
which is to use the real domain with the hope there is no strong checking.

- Employees and others using a highly restrictive domain outside their
intended purposes.

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

---

From: Tony Hansen <[email-masked]>
Date: Mon, 31 Jul 2006 15:02:59 -0400

> does not make the DKIM d= domain.)

I would at a minimum include rfc2822.Sender in this check: third part
signing is when the DKIM d= domain is not equal to either the
rfc2822.From's domain nor the rfc2822.Sender's domain.

	Tony Hansen
	[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Mon, 31 Jul 2006 12:26:45 -0700

> rfc2822.From's domain nor the rfc2822.Sender's domain.

Tony, et al,

Switching back to the 'requirements' suggestion I have been making:

I would like to see a scenario described that explains exactly what problem
needs to be detected and why it is a compelling, immediate requirement.

I would like to see the description done in a way tht talks about particular
individuals and organizations, without referring to particular protocol units.

In other words, I'd like to see the non-technical description of the requirement
and its rationale, before it gets translated into the technical details, such as
citing particular header fields.

d/

-- 

  Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 31 Jul 2006 16:44:52 -0400

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "Tony Hansen" [email-masked]

> I would like to see a scenario described that explains exactly
> what problem needs to be detected and why it is a compelling,
> immediate requirement.

It serves no justice to try put all the work already done into spigetti mail
threads.

The TA issues and discussions highlighted many of this and I believe the
latest Threats draft does also highlight much of this.

The following diagrams shown here were modeled on SSP, from which the DSAP
"fill in the holes" proposal was based on:

   http://www.winserver.com/public/ssp/ssp.htm

Hopefully DSAP will be officially announced in today's batch new IETF I-D
drafts:

  http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.txt
  http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html

To answer the subject title question:

   "Are verifiers expected to query SSP on a successful verify?"

My position has always been that its a chicken and egg issue, and also a
implementation design consideration.

But when considering the "security" aspect of DKIM-BASE, the ideal model
calls for an SSP lookup at all times in order to secure the most obvious
possible exploitations such as:

    - Sign or no sign, No mail was expected
    - The mail was not signed and it was expected to be signed.
    - The mail was signed and it was not expected.
    - The mail was signed by 3rd party and it was not expected.

and none of this highly possible transactions require DKIM signature
verification yet.  So it can beviewed as an optimization consideration as
well.

The debates centered around;

    - Redundant DNS lookup concerns,
    - Invalid signatures sufficient for non-accepability,
    - Valid OA or 3P signatures have the same level of trust.
    - Multiple signatures matrices.

I think most agree that in todays world, although always a concern,  the
question of redundant DNS lookups should not be a show stopper.

When "ignore invalid" signatures became the written in stone policy in
DKIM-BASE, this only served to highlight the need for a SSP concept.
Failures can not be ignored.

The question of OA vs 3P was simply a matter of trust and the long debated
solution was requirement to have a "allow list" somewhere.  Of course, the
concern of lenght issues was among it.

The Multiple Signature Matrices is probably the most complex part of this
DKIM framework because it deals with the 3PS issues, the Mailing List
issues, the mail integrity issues.  Currentlly the DKIM-BASE model allows
for the validation of detected failure in multiple signed messages if and
only if,  atleast one signature is valid.

Anyway, the redundancy DNS lookup concerns resurface with a multple
signature message.

My personal engineering opinion, that one failure is enough for a negative
classificaton.   But when mixing in mailing list issues, this is probably
the only way to make DKIM work with mailing list servers (MLS).

Howver, as my DSAP draft proposals,  we can minimize these multiple
signature mailing list problems with a SSP lookup to again, avoid the most
fundamental exploitations that I outlined above.    The simpliest example is
a MLS pre-empting failure by confirming the DKIM usage of an email address
during the subscription process:

3.3.  Mailing List Servers

   Mailing List Servers (MLS) applications who are compliant with DKIM
   and DSAP operations, SHOULD adhere to the following guidelines:

   Subscription Controls

      MLS subscription processes should perform a DSAP check to
      determine if a subscribing email domain DSAP policy is restrictive
      in regards to mail integrity changes or 3rd party signatures.  The
      MLS SHOULD only allow original domain policies who allow 3rd party
      signatures.

   Message Content Integrity Change

      List Servers which will alter the message content SHOULD only do
      so for original domains with optional DKIM signing practices and
      it should remove the original signature if present.  If the List
      Server is not going to alter the message, it SHOULD NOT remove the
      signature, if present.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 31 Jul 2006 17:30:30 -0700

On Jul 31, 2006, at 12:26 PM, Dave Crocker wrote:

>
> I would like to see a scenario described that explains exactly what  
> problem needs to be detected and why it is a compelling, immediate  
> requirement.
=====

Problem 1:  Spoofs of the 2822.From email-address(es) common with  
various phishing or spoofing attempts.

Solution A:
When the 2822.From email-address is not accompanied by a valid  
signature from a parent domain, policy related to the 2822.From email- 
address domain might provide a means to block spoofs of direct  
messages.  Acceptance would be denied when policy indicates 2822.From  
email-address domain must be signed by a designated domain and this  
condition has not been met.

Drawback of solution A:
a) A recipient can not differentiate direct messages from other  
message types.  The required use of a designated signing domain will  
not conform to many common indirect services made on behalf of a  
2822.From email-address such as mailing-lists or e-invites, for example.

b) The 2822.From email-address may not be visually apparent or may be  
visually misleading.  When just display-names are visible, or look- 
alike or international domains are used, the recipient may be unable  
to discern the exact 2822.From email-address being displayed.

-----

Solution B:
Track the tuple of 2822.From email-address domains and signing  
domains at the MUA by way of the address book or correspondence log.   
Annotate messages matching these tuples.  This does not require that  
a policy relationship be established.

Drawback of solution B:
This introduces a new requirement for MUAs to annotate and for the  
tuple information to be exchanged between disparate MUAs for the same  
user.

=====

Problem 2: Spoofs of visual content where 2822.From may also be  
contrived to be visually misleading.

Solution C:
When a domain can be ascertained from the visual content of a message  
and is not signed by a parent domain, policy related to the domain  
identified by the visual content might provide a means to block  
spoofs of direct messages based upon 2822.From policy.  Acceptance  
would be denied when policy indicates visual content must be signed  
by a designated domain and this condition has not been met.

Drawback of solution C:
There is no reliable proactive means to identify cognitively similar  
message content when ascertaining which policy should be applied.   
This would not have a direct policy being expressed and may be highly  
prone to false positives.

See Solution B.

=====

Problem 3: SMTP Host-name utilized within the administrative domain  
by compromised systems.

Solution D:
Authenticate the reverse DNS hostname or EHLO and then reference DKIM  
policy for the host-name for designated signing domains.  A valid  
DKIM signature by a designated DKIM domain would validate the  
administrative' control of the message's introduction and satisfy the  
conditions of the policy.

Drawback of Solution D:
There can be an immense number of DKIM domains associated with an  
SMTP client host-name.  While there are techniques to efficiently  
resolve a name:name relationship using DNS (query of <signing- 
domain>._policy-label.<related-domain>), the number of domains and  
the maintenance of these relationships by a single administrative  
domain may be daunting.

-----

Solution E:
Require a DKIM sanctioned method be used to authenticate SMTP client  
host-names.  For example an address RR must found at _dkim.<host- 
name> that validates the client. The EHLO could also encompass the  
_dkim.<hostname> as a means to avoid replicate A records and to  
signal use of dkim at the EHLO.

Drawback of Solution E:
This would only protect systems that never send email and thus have  
not been assigned a _dkim specific IP address.

=====

Problem 4: Replayed messages and bogus signatures are difficult to  
detect.

Solution F:
By designating a direct relationship at the signing domain (&  
2821.Mail_Froms) for designated host-names, invalid signatures should  
be considered bogus and valid signatures should not be considered a  
product of replay.

Drawback of solution F:
These relationships of possibly disparate administrative domains may  
be daunting.  These policies would not offer a basis to refuse the  
message when a designated host-name is not discovered.

=====

Problem 5: Spoofing of the Current Address as determined by the  
sequence of 2822.Resent-Sender, Resent-From, Sender, or From.

Solution G:
Reference a specific DKIM policy of the Current Address for  
designated signing domains.

Drawback of Solution G:
This may lead to additional loading of the DNS server when some  
verifiers attempt to validate every header field within the message.   
As this field is not likely to be the target of a spoof, the added  
overhead may be considered unwarranted.

=====

Problem 6: Spoofing of the 2821.Mail_From

See Solution F:

-----

Solution H:
Attempt to impose the 2822.From policy upon the 2821.Mail_From in  
lieu of a separately defined policy specifically for the 2821.Mail_From.

Drawback of solution H:
Can only be used to bypass some checks.  Lack of an association can  
not be acted upon to refuse the message.

-Doug