[ietf-dkim] SSP Responsibility Delegation - Security Concerns

[Hector Santos]

----- Original Message -----
From: "Douglas Otis" <dotis at mail-abuse.org>

>>  Is this a threat to company.com? Yes.
>
> No. Either this is prevented or a different signing domain is
> used. When there is no designated domain, there is no
> expectation the 2822.From is valid.
>
> It would seem Hector would advocate a separate flag indicating
> whether the 2822.From is valid as a separate assertion from by
> whom it should be signed.  My view differs in this case.  Either
> the 2822.From is valid or don't list a designated (authoritative)
> domain in the policy.  A flag that signals a required signature
> without an assertion the 2822.From is valid offers little
> protective value.

I'm not sure what this means, but we still have the DKIM-BASE hashing of
2822.From.  Thats a great assertion for validity.

I argue only that it is unsafe for company.com to be using his domain
promisculously after it has arranged for his mail to be signed by anyone or
himself.  If he wants to do that, fine.  But he should atleast declare such
a relaxed policy.

He doesn't know what will happen at mailinglist.com.  Maybe tomorrow
mailinglist.com will find a different ISP.  Who knows?

But if domain wants to allow that, I don't see it as any different than
other relaxed domain policy.

> The goal that Hector is seeking represents a desire to list
> who should sign without making any assertion regarding the
> validity of the 2822.From.  While not agreeing with that use,
> a policy could be structured to accommodate that use as well.

Lets not forget there is still DKIM-BASE.  The tie in would be the hashing
of the 2822.From: header.  The signature still needs to verify.

All we are doing here is a simple policy concept to says the signature was
expected to be signed by either the OA or some 3rd party.

If the domain doesn't care and doesn't designate a 3rd party signer or will
be using his domain loosely, then there is nothing the verifier can do.  But
is the domain protecting itself?  I don't think and its not doing one any
favors.

All the verifier can do is do some upfront checks for consistency.

After that, its up to the local policy what they want to do. They want to
buy some DAC batteries, excuse the pun <g>, thats fine.  But I am not going
to spent an investment on DKIM solely on membership only DAC batteries.

I think this is simply to just eliminate the most obvious of potential
loopholes:

- Is domain being used for mail when it should not?

   This can happen now. Bad guys blindly using a domain.
   DKIM domains will benefit to protect domains that not
   used for mail. Very simple to eliminate.

- Was it suppose to be signed?

   Did some bad guy who knew nothing about DKIM blindly
   harvested some domains began to spoof the domain without
   a signature?  This is what I call an "Indirect Attack."
   Very simple to eliminate.

- Was it support to be unsigned?

   Did some bad guy try to fool the system somehow, and
   began to sign mail - valid or not?  This is what I
   call a "Direct attack."  Very simple to eliminate.

- Was it really strict with only the first party?

   Did some bad guy try to use a 3rd party party to
   fool randomly targeted systems?  Again, very simple
   to eliminate and help protect these "High Value"
   domains.

- Is a 3rd party signinature ok?
- And if they want to be more strict, which 3rd party?

   if a 3rd party was found, did the domain
   allow it?  and if so, was there a specific domain
   allowed? Very simple to eliminate.

Very basic stuff.

After that, in my opinion, there is nothing the verifier can do.  The policy
was checked and if they is a signature, run it by DKIM-BASE.  That's it.
Simple.

If we want to remove the delegation, then in my view, we are either going to
make it more strict with a no 3rd party flag or completely openness where
anyone can sign.

So the delegation is a middle ground for those people who don't want to be
100% strict with OA only signatures and yet do not just want anyone signing.

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