Subject: [Asrg] 6. Proposals - Sender Authentication - DNS + PKI

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 22 Nov 2003 19:09:31 -0500

From the following article:

http://www.internetwk.com/breakingNews/showArticle.jhtml?articleID=16400308

-------------------------
"One organization working on sender-authentication mechanism is a 
commercial alliance comprising the biggest consumer e-mail providers: 
Microsoft, Yahoo, America Online and Earthlink."

"Under the proposal, ISPs and any other organization with their own 
domain name system (DNS) would use a private key in their mail servers 
to place an encrypted code in the header of each piece of outgoing mail. 
When the mail arrived at its destination, the receiving mail server 
would get the sender's public key from its DNS server to decrypt the 
header, thus verifying the message's origin.

If the message is spam, or even a legitimate marketing message the 
receiver doesn't want, then email from that DNS can be blacklisted, or 
automatically blocked. "Once you have identity, then you can establish 
reputation and trust," Libbey said. "Those are really important concepts 
in e-mail."

Yahoo has done some proof-of-concept testing of the idea internally, but 
the technology is still at the early stages of development and no 
timetable for general release has been set."
-------------------------

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Philip Miller <[email-masked]>
Date: Sat, 22 Nov 2003 22:19:44 -0500

> http://www.internetwk.com/breakingNews/showArticle.jhtml?articleID=16400308

The quoted description sounds like an end-to-end implementation of a
designated outgoing MTA protocol. This actually sounds better, on first
impressions, than the current LMAP ideas, for three big reasons. First, this
would be easier for senders to implement, because it doesn't require listing
every MTA in DNS and it keeps configuration of a new MTA confined to that
machine (all that has to be done is loading the private key). Second, it
would require much less change to DNS, because only a single new record
would be needed for each domain, rather than one for each server sending for
that domain. Third, it would eliminate the issues of forwarding (.forward,
aliases), because it checks the message originator in all circumstances.
Indeed, it could allow for more trustworthy forwarding if the intermediate
MTA were also checked.

Now, my concerns: why have they not published a technical proposal for this
yet? If there's anyone from the members of this alliance on this list, could
they please step forward? Much more would be achieved by doing this
publicly, and we've seen time and again that the IETF process works pretty
damn well at working out problems before they become standards.
Also, the comment about organizations with their own DNS doesn't sit well
with me. From the rest of the description, it should be fine for anyone with
their own domain name and mail server, not their own DNS server as the quote
seems to imply.
Finally, the reporter's remark about blacklisting based on this is
senseless, because new domains are easy to obtain. This has already been
stated multiple times.

 From a different part of the article:
"The ASRG is considering three major proposals, Reverse MX, Sender Permitted
 From and Designated Sender Protocol, John R. Levine, co-chair of the
organization said.
"They're bascially all variations on the same theme, which is the attempt to
identify mail that's not coming from where it should," Levine said."

Perhaps Alan DeKok would be more qualified to comment on this, but this
statement is not really accurate in light of the work on a combined LMAP draft.

--
Philip Miller

---

From: Dave Crocker <[email-masked]>
Date: Sun, 23 Nov 2003 10:06:49 -0800

PM> impressions, than the current LMAP ideas, for three big reasons. First, this
PM> would be easier for senders to implement, because it doesn't require listing
PM> every MTA in DNS and it keeps configuration of a new MTA confined to that
PM> machine (all that has to be done is loading the private key).

in fact, it does not specify that it must be the domain of the MTA.
Perhaps it is ok to have the domain of the author (From/Sender).

This would be an enormous improvement over the typical proposals that
requiring pre-registering a From domain with an MTA domain.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Walter Dnes <[email-masked]>
Date: Sun, 23 Nov 2003 20:37:13 -0500

On Sat, Nov 22, 2003 at 07:09:31PM -0500, Yakov Shafranovich wrote

> "Under the proposal, ISPs and any other organization with their
> own domain name system (DNS) would use a private key in their mail
> servers to place an encrypted code in the header of each piece
> of outgoing mail.  When the mail arrived at its destination, the
> receiving mail server would get the sender's public key from its
> DNS server to decrypt the header, thus verifying the message's origin.

  Why do they need an encrypted header ?  Wouldn't a list of valid
sending domains or IP addresses be sufficient ?

  Another worry is compromised home machines.  A trojan can call the
Windows API and run the dialup-and-send-email processes.  For all
intents and purposes, the end-user might be sitting at the keyboard.
There is no for the ISP way to tell.

-- 
Walter Dnes <[email-masked]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did

---

From: Markus Stumpf <[email-masked]>
Date: Mon, 24 Nov 2003 12:17:20 +0100

> Perhaps it is ok to have the domain of the author (From/Sender).

It makes me wonder why just AOL, Yahoo and Hotmail bring this proposal.
If it were a big ISP with thousands of customers all with their own
domain I'd understand. But with that crypto cookie in the header based
on a domain all I could do is either block e.g. AOL as a whole or not
block any mail from AOL at all.
So the solution is only helping THEM to reduce the spam sent into their
systems, but it doesn't help any one else if the spam is injected
via webmail*yahoo.com or *aol.com.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 24 Nov 2003 13:52:37 -0500

Philip Miller <[email-masked]> wrote:
> impressions, than the current LMAP ideas, for three big reasons.

  It's substantially similar in concept to LMAP if it does header
verification, or PGP signing, if it does body verification.  Without a
more complete description, I can't tell for sure.

  If it authenticates the message body, then it has the problem that
PGP and S/MIME has: broken MTA's mucking with the message content.
It's not critical, but it is a consideration.  Another consideration
is that the recipient then has to receive the entire message before
the signature can be validated.  Solutions which work on headers alone
may have more efficient use of network resources.

  If it authenticates the headers, then the "encrypted code" in the
header can be re-used in other, unrelated messages, to send spam.
Time limits can be put on the tokens, but that's basically a hack
around an inadequate design.

  e.g. Some choices for the token, and pros/cons:

  token = signature(nonce) + nonce
    pro: simple
    con: easily stealable

  token = signature(nonce + source IP) + nonce
    pro: better
    con: forwarders don't have the same source IP, and can thus
         claim to be "forwarding" mail, to spam people

  token = signature(nonce + source IP + timeout) + nonce + timeout)
    pro: better
    con: still onl limits impact of attack, but doesn't prevent
         the attack.

  I'd like to see a signature scheme for headers only which can't be
trivially attacked or abused.  I'm not sure one exists.

> First, this would be easier for senders to implement, because it
> doesn't require listing every MTA in DNS and it keeps configuration
> of a new MTA confined to that machine (all that has to be done is
> loading the private key).

  Which will REQUIRE communication with the owner of that public key.
This isn't substantially different than the work required to set up
LMAP:  "please give me key", versus "please list X in DNS".

> Second, it would require much less change to DNS, because only a
> single new record would be needed for each domain, rather than one
> for each server sending for that domain.

  That is true.  The ongoing maintenance costs of this solution will
be lower than that for any LMAP solution.

> Third, it would eliminate the issues of forwarding (.forward,

  Once you have forwarding, it can be abused to send spam.  See the
discussion above.

> yet?

  Politics.

> statement is not really accurate in light of the work on a combined

 There is no combined LMAP draft.  There is an LMAP evaluation
document, which discusses the costs and benefits of LMAP-style
proposals.

  The article goes on to say:

   "The technologies would allow a mail server receiving a message to
   query the domain that a message purports to be from, asking if the
   server that sent the mail is authorized to send from that domain."

  I prefer the *positive* statemente of the design goal of LMAP over a
negative one.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 24 Nov 2003 14:00:39 -0500

> sending domains or IP addresses be sufficient ?

  Then it would be LMAP.

> There is no for the ISP way to tell.

  All messaging systems suffer from this vulnerability.  There is no
way to stop it.   Therefore it doesn't make sense to try to stop it.

  Instead, it makes sense to design systems which allow the abused
originator to discover the abuse, and deal with it.  Systems which
have been tried or proposed are various methods of accountability
tracking, content filtering on outgoing mail, etc.

  Alan DeKok.