ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Are verifiers expected to query SSP on a successfulverify?

2006-07-31 11:49:28

----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Monday, July 31, 2006 12:38 PM
Subject: Re: [ietf-dkim] Are verifiers expected to query SSP on a
successfulverify?


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.)

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









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