----- Original Message -----
From: "Arvel Hathcock" <arvel(_at_)altn(_dot_)com>
It seems to me that a 3rd party signer needs to look
up the ORAD SSP to see if any 3rd party signing is
allowed in the first place.
Humm... interesting idea.
In a way it is similar to SPF, where the SPF receiver checks to see if a
sender is allowed to post on the system based on a domain::IP association
verification.
SPF does it on the SENDER DOMAIN.
SENDERID/PRA does it on the FROM: or SENDER:
This would make it the responsibility of the
signer to do the policy checking but it seems that this move wouldn't
change
verifier requirements. The verifier can't assume that a "3rd party"
signature which it finds in a message was placed there by a signer that
played by the rules and did an SSP check first. Since this is the case,
might as well leave the responsibility on the verifier IMO. In other
words,
since the verifier can't trust the signer and must do an SSP anyway why
have
the signer go to this trouble? What do you think?
Well, I think like Earl mentioned, it would be "good behavior."
If the protocol suggests that all parties will exhibit a higher intelligence
to solve the phishing/spoofing problem, then all parties has to comply in
both directions, otherwise I don't see how (yet) it will work very well
(i.e., the result trust is low).
Currently, when you allow third party signatures you can be phished and
spoofed. But this is no different than being phished and spoofed by not
using DKIM at all.
The difference is that you trying to do something with DKIM which makes a
presumption of a "higher level of intelligence or compliance." So you now
have a new level of possible social engineering issue. You have watch out
for any new sense of "False Security" which may develop (false positives and
false negatives).
"Cool! That sysem is using DKIM!!! My mail is safe and all
new mail I get will be authenticated"
The difference with the signer checking the OA SSP, we now increase the
outcome of the desire expections. If you know for sure that a signer does
not check the policy of the OA, then you are left in a limbo. But if you
know it did OA SSP checking, then atleast you a better sense of the
security.
The stronger the SSP policy, but better the outcome (for the sender and the
user). The trouble begins when you have relaxed provisions in the
specification.
We shouldn't be surprise. SMTP has relaxed provisions thus why we have a
problem in the first place. SPF tried to close this SMTP loophole, but
introduced its own relaxed provisions so DUH - exploitation started.
We should not expect any less issue with DKIM relaxed provisions. Murphy's
law. If there is a loophole, it will get exploited.
Even if we changed the spec to say that signers must
comply with the SSP wishes of the ORAD, this does not eliminate the attack
vector because phishers and spoofers can just not do that and sign anyway.
So, verifiers must be responsible for SSP right?
I think you can't get away from checking the OA SSP, on both ends, 3rd party
signers and verifiers. In addition, I don't think DKIM by itself is
sufficient with out some level of IP path analysis too.
You have a exclusive SPF policy. No one can use ALTN.COM outside your
domain network. Even if a message from ALTN.COM is 100% verified DKIM
signature is a moot point if the SPF check fails.
SPF did a "SSP" check for your return path to check your outbound mail
policy. I don't think DKIM can get away from using a similar concept if it
is trying to address the 3rd party phishing/spoofing issue.
My own feeling on the "3rd party" signing issue, if you want to specify
the
authorized "3rd parties", this needs to be done in the policy record. I'm
hoping there is something we're overlooking (like a mechanism that
involves
just using a different selector or something entirely) to get around this
problem. It seems like there's a better solution but I can't grasp it.
The problem with a "3rd party List" is that it can become a maintenance
nightmare. If an employee wants to use a company's domain on a 3rd party
server, he will need to put in a request to white list (update DNS) the 3rd
party server in the company's DKIM 3rd party list.
This might actually be very good for a high value domain system, i.e.,
paypal.com, Citibank.com, etc. The company lawyers might even like this
idea as it minimizes non-business mail security issues.
But it might be a burden for the general network. Maybe not. Maybe it just
a matter of programming it (the automation) and making it all happen. :-)
Nevertheless, the phishing/spoofing problem will remain as long as we have
relaxed provisions in a protocol where one or more components of the flow is
not performing any OP checks.
Ironically, I should note even I got confused about the SSP vs. the KEY
policy.
I thought the SSP was part of the key policy. I naturally thought that is
where it makes sense on a per KEY basis.
I added a tms1._domainkey.santronics.com TXT record and it has the o=~ tag!!
Why isn't this part of the PER key policy?
It is a per domain. Not per selector. I think having it per selector as a
domain override might help address part of this problem.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com