Jim, thanks for the feedback.
----- Original Message -----
From: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
Example loopholes:
1) A message is signed, but the SSP indicated a "o=." (No mail
expected from domain).
There has been a lot of discussion of "o=." but it's not actually
in the current version of the SSP draft. I personally don't
think it's really necessary. But that's probably a better topic
for later.
Ok. I suggest that we not close protocol options yet. Lets look for all
the possibilities, outline it, jot it down and then we work it out.
Just to the point, AltaVista.com has a "Never Expect From Us" email
policy. A TXT lookup provides:
Non-authoritative answer:
altavista.com text =
"This domain sends no email"
altavista.com text =
"Null SPF is for tracking purposes only"
altavista.com text =
"All mail claiming to be from altavista.com is forged"
altavista.com text =
"v=spf1 +exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.altavista.com -all"
I think DKIM should offer the same. I will probably do the same soon
for 4-5 our domains.
In the presence of a "no signature expected" policy, would a message
with a valid signature be more suspicious than one without?
This is a rethorical question. Do you know and prove it isn't a threat?
These are decisive decisions based on having low information and few
options to take.
It is the possibility that it can exist. The "ideal" (as oppose to
practical) solution is to get more information, and in this case, check
the domain policy and this provides more appropiate options to take.
That solves the problem.
The question of whether it is a 'feasible idea' should be left for
design
implementation discussions. But without it, it is a possible threat
until you can prove otherwise.
But if no signature is expected, why would the OA domain have
any keys published in the first place?
Exactly. Again, rethorically, could a bad actor use this scenario as an
exploit?
Me?
My simple policy change offer a greater value to all parties.
Default SSP should be NO POLICY. Force the issue with DKIM
domain policy implementation. If they want to use it, be
specific. Don't leave it up to verifiers what your intent
really was.
But this should part of SSP discussions.
3) A message is signed by a 3rd party, but the SSP indicated a o=!
policy where the original domain signature is required, and a 3rd
party signature is not expected but allowed to be present.
Note: The o=! policy can be a defined a "near exclusive" policy,
but it is not an absolute exclusive policy consideration.
I'm afraid I don't follow this.
This is to point out there is no longer (never was) a 'true' exclusive
security benefit with SSP. Since you clarified what this policy is,
it highlights the possibiluty that it allows for any 3rd party entity to
"touch" the message.
If you allow it to happen, it can be exploited. How and why? Who knows,
but bad actors are creative and will figure out how to exploit this.
But more important, it also lowers the reliability of the policy and
confidence lever of a domain wanting to use this. The "hole" exist so
IMO, it should be noted in the TA.
Sorry, I'm not following this either. It seems the threat has
to do with receipt of signed messages when none should be
expected. But isn't this addressed simply by not publishing
any key records?
Maybe. But I think it the fake ones that could cause grief. We don't
know how it can use. But the door is open. That is all my point here is
about.
Each of the examples I showed have their own specific level of
likelihood, detection and impact. The overall common issue is
consistency of the signature vs policy expectations. This in itself is
a major threat.
The most perfect analogy is the "SMTP rule" that the return path should
reflect the sender address. Since the SMTP protocol is relaxed and has
no required provision to validate this address, it has become the #1
exploited feature of SMTP. It is the basis for many forms of email
attacks, spam, spoofs, bounce-attacks as used by SORBIG generation
e-virues using a dual level distribution scheme: Try directly the RCPT
address, if accepted and then latter rejected, exploit the expected
bounce system itself to bounce it to MAIL FROM, etc, etc. - a dual level
addressing attack.
Here is what I hope we don't duplicate:
RFC 2821, section 7.1
7.1 Mail Security and Spoofing
..
This specification does not further address the authentication issues
associated with SMTP other than to advocate that useful functionality
not be disabled in the hope of providing some small margin of
protection against an ignorant user who is trying to fake mail.
It isn't a few ignorant bad actors any more, but an entire industry.
It it my hope to highlight these critical points and that we avoid
repeating the same type of relaxed protocol provisions mistakes with
DKIM without thinking it all out very thoroughly.
Look at this another way:
How about legacy software?
You can put money in the back that all SMTP systems will still need to
support legacy clients.
The best way to avoid any new security concept, is for the the Bad Actor
to avoid it. In order words, they won't use DKIM. They won't sign the
message. They won't raise any red-flags.
So where is the protection? Where is the pay off?
In leiu of having prior information about the sender, what we can't
avoid the segment of bad actors who DO try to use DKIM in some form or
fashion to be ignored.
In other words, by using DKIM or trying to exploit, it raises the bar to
a new level that is ABOVE backward compatible operations.
This is the protection begins. But if the protocol is full of relaxed
provisions making it essentially all optional, then you lose a good bit
of this protection and the end result is that a SMTP system, having to
support legacy software anyway, will punt on DKIM processing and just
put ignore any information about it.
The two extremes policies are:
NEVER (o=.)
EXCLUSIVE (o=!)
But we now relaxed EXCLUSIVE so it really isn't exclusive anymore but
more of a STRONGER policy over the STRONG policy as you initially
indicated you referred to it. So we lost some protection there.
In any case, the devil's details is not what I was trying to extract
here, but to highlight that not following consistent protocol
expectations is a threat itself.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org