----- Original Message -----
From: "Arvel Hathcock" <arvel(_at_)altn(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Other companies may decide that it's unwise to
completely relax policy on a domain-wide scale
simply to allow mailing list use. For those, putting
list participants on a separate sub-domain could
solve the problem.
If a DKIM ready mailing list server or public email service is concern about
controlling possible abuse, it MUST lookup the SSP at all points of entry.
There are two angles to the DKIM protection scheme.
- The domain owner protecting his domain with a
declared and exposed DNS SSP policy, and
- An EMAIL system protecting the service from becoming
a source of mail fraud by pre-empting the opportunity
for abuse.
For example, never mind Alice wanting to subscribe and post to a
list. What if someone else wanted to use her domain to subscribe
or post into the mailing list?
Lets look at the current procedures using IETF-DKIM with the
added idea that it is running on a DKIM ready system.
1 - Alice goes to the web site to subscribe.
http://mipassoc.org/mailman/listinfo/ietf-dkim
2 - Alice enters the following info to subscribe:
Your Email Address: alice(_at_)exclusive(_dot_)com
Your name (optional):
Pick a password: *******
Reenter password to confirm: *******
[SUBSCRIBE]
When she clicks the [SUBSCRIBE] button, we have three possible design
scenarios:
2.1 - DKIM READY system with NO SSP checking
2.2 - DKIM READY system with DELAYED SSP checking
2.3 - DKIM READY system with IMMEDIATE SSP checking
Lets look at 2.1 with NO SSP checking:
2.1.1 - A confirmation message is sent to alice(_at_)exclusive(_dot_)com
Alice has two ways to respond to the confirmation message.
2.1.1.1 - Alice can click on the HTTP URL to confirm.
2.1.1.2 - Alice can click reply keeping subject the same.
With 2.1.1.1, clicking the HTTP URL, Alice will be confirmed and
a welcome message is sent back to Alice.
With 2.1.1.2, Alice sends a reply and Alice's ISP or server sends
an exclusive.com DKIM signed message back as a mailing
list confirmation control message. The Mailing List server
DKIM verifies the exclusive.com DKIM signed message and completes
the confirmation process.
[THREAT] So we have a loophole threat with 2.1.1.1 HTTP URL confirmation
methods for DKIM ready systems allowing Alice to subscribe to the list and
we have a loophole with 2.1.1.2 Reply confirmation methods when the verifier
accepts the exclusive policy message and allows Alice to subscribe to the
list.
Lets look at 2.2 with DELAYED SSP checking:
2.2.1 - A confirmation message is sent to alice(_at_)exclusive(_dot_)com
Alice has two ways to respond to the confirmation message.
2.2.1.1 - Alice can click on the HTTP URL to confirm
2.2.1.2 - Alice can click reply keeping subject the same.
With 2.2.1.1, clicking the HTTP URL, the HTTP GET web service,
cgi or otherwise will perform a SSP lookup for exclusive.com
and reject the confirmation.
With 2.2.1.2, Alice sends a reply and Alice's ISP or server sends
an exclusive.com DKIM signed message back as a mailing
list confirmation control message. The Mailing List server
DKIM verifies the exclusive.com DKIM signed message, however, since this is
a exclusive policy, a confirmation rejection message is sent back to Alice.
The service rejects it because it realizes the distribution will have
downlink conflicts with this policy.
Lets look at 2.3 with IMMEDIATE SSP checking:
In this scenario, as soon as ALICE clicks the [SUBSCRIBE] button,
the server will lookup the exclusive.com SSP and restrict the
usage of this exclusive domain.
In summary, no matter what, the service must check the SSP at all
levels. It can either be immediate or delayed. A delay
implementation might be most costly in design changes. An immediate SSP
check closes the entry point and appears to be a less costly design change.
However, if SSP policy checking is not done as shown in 2.1,
then the protection is left for the distribution downlinks
and now we have a OPEN-DKIM-RELAY situation. This site can
now be used as a source to spoof any high-value domain.
Understand?
Repeated Conclusion:
If a DKIM ready mailing list server or public email service is concern about
controlling possible abuse, it MUST lookup the SSP at all points of entry.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org