Subject: [Asrg] 6. Proposals - DNS + PKI - Yahoo's "Domain Keys"

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 06 Dec 2003 20:27:04 -0500

[Subject was "Re: [Asrg] 0. General - Yahoo proposes new Internet 
anti-spam structure", changed as per posting guidelines. Mod.]

Hector Santos wrote:
 > FYI,
http://www.usatoday.com/tech/news/techinnovations/2003-12-05-yahoo-spam-switch_x.htm
 > --Hector

Thanks Hector for the link, this story has already been mentioned in a 
few other places as well.

The basic thrust of this proposal is that the sending domain will have a 
public key stored in DNS, and sign every email from that domain with the 
private key. The receiver can check validity by getting the public key 
from DNS, and verifying the digital signature. Same purpose as LMAP, but 
via PKI.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Power tends to corrupt, and absolute power corrupts absolutely" (Lord 
Acton)
-------

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

---

From: Philip Miller <[email-masked]>
Date: Sat, 06 Dec 2003 23:45:06 -0500

Here's a quick, off-the-cuff comparison of these two approaches:

LMAP Purpose: prevent domain name forgery of HELO/FROM
Domain Keys Purpose: prevent domain name forgery within message headers

LMAP Costs: single DNS lookup and maybe a comparison
Domain Keys Cost: DNS Lookup, cryptographic function, possibly once per 
transitted MTA

LMAP advantages: simple to implement - replace rDNS/A lookups by current MTAs
LMAP disadvantages: continuing question of forwarding in various scenarios

DK advantages: prevents forgery in forwarded situations, such as if a 
mailing list owner inserts a forged message on the list.
DK disadvantages: high burden of software implementation, requires receipt 
of DATA before an authoritative check can be done

I think that if the design of these two approaches is coordinated, they can 
be quite complimentary. Unfortunately, I haven't seen any Yahoo 
representatives on this list yet, so I'm a little bit worried.

Philip Miller

---

From: Bill Cole <[email-masked]>
Date: Sat, 6 Dec 2003 23:54:35 -0500

>Domain Keys Purpose: prevent domain name forgery within message headers

Do we really know anything technical about DK? All I've seen is that 
Yahoo press release, and it is pretty fuzzy. I wouldn't want to make 
much in the way of technical conclusions cased on that.

-- 
Bill Cole                                  
[email-masked]

---

From: Philip Miller <[email-masked]>
Date: Sun, 07 Dec 2003 00:14:17 -0500

> much in the way of technical conclusions cased on that.

I based that assessment on the text

> Under Yahoo's new architecture, a system sending an e-mail message would
> embed a secure, private key in a message header. The receiving system
> would check the Internet's Domain Name System for the public key
> registered to the sending domain.
> 
> If the public key is able to decrypt the private key embedded in the
> message, then the e-mail is considered authentic and can be delivered. If
> not, then the message is assumed not to be an authentic one from the
> sender and is blocked.

Yes, it gets the mechnics of public-key crypto wrong, but the idea is pretty 
clear.

Philip Miller

---

From: "Alan DeKok" <[email-masked]>
Date: Sun, 07 Dec 2003 10:26:29 -0500

> of DATA before an authoritative check can be done

  It has other issues.

  If the outgoing MTA signs the packets, then all users for that
domain are required to send mail through machines administered in the
same domain.  i.e. no roaming users being "lazy", and just sending
mail directly to the recipient.

  All of the objections to LMAP about this problem then apply to DK.
Even worse, LMAP allows the domain owner to permit roaming users to
continue their existing behaviour.  Having the domain owner force
users to send mail through the domain's MTA is an *option* in LMAP.
So LMAP gives the users and domain owners more options than DK.

  If DK means that each sender signs the message, then you have two
choices.  One is to have a domain-wide private key, in which case it
must change regularly, as spammers will quickly obtain it.  The second
is to have per-user private keys, in which case DNS lookups have to be
done to get the key for each user, which is problematic.  (Why not
just then have every domain put user authentication information in
DNS, and have every recipient MTA do SMTP AUTH?  It's entirely
equivalent, and doesn't require much in the way of user-agent
changes.)

  I don't think the second option is useful.

  The first option means that not only do we have to update each user
agent to sign the keys (updating millions of clients is a difficult
problem, even for AOL), but we also have to distribute new keys every
so often.  This will be a signficant ongoing maintenance cost.  The
key distribution will be problematic (what if you've been off-line for
a week?)...

  In contrast, LMAP has a small additional cost when a new MTA for a
domain is configured, or when MTA's change IP address.  It has no
continual maintenace required, like DK does.  I'd be *very* surprised
if DK had a lower ongoing maintenance cost than LMAP.

  Further, if the user agents sign the messages, then we can be pretty
much guaranteed that spammers will have, and abuse, the keys in
seconds.  Spammers already maintain distributed databases of open
proxies.  Distributing new keys for a domain is no more expensive.

  So the system has signficant cost to deploy, and will do *nothing*
to prevent spammers from sending messages, even forged messages from
"owned" machines, or open proxies/relays, like they do today.

  While LMAP also permits spammers to continue to send spam "from" a
domain, they can do so only under two conditions.  One is with the
agreement of the domain owner (who lets roaming users forge, too.).
The second is if they "own" machines in a domain, and abuse those to
send spam.

  The first scenario doesn't interest me.  The second is more useful.
It means that spammers can continue forging ONLY if they engage in
behaviour which is criminal in many jurisdictions.  So LMAP leverages
additional anti-spam resources, making it more effective than it would
have been on it's own.

  Alan DeKok.

---

From: Matthew Elvey <[email-masked]>
Date: Sun, 07 Dec 2003 12:13:50 -0800

Add'l problems already evident:
1)Not an open standard (not a standard at all.)
2)Not even a press release about it at 
http://promo.yahoo.com/pressroom/releases.html - I searched for a while; 
the ONLY source for any info seems to be a Reuters article !!!  I see no 
evidence that the software that the article mentions even exists.  Yahoo 
isn't claimed to be offering it free to proprietary developers.
3)Makes deniability more difficult than LMAP (mostly a good thing).
4)Requires all authorized SMTP servers have new software, be configured 
to use it and the domain's secret key, AND be secure.  I could implement 
an LMAP scheme today; I couldn't implement anything based on Yahoo's 
idea, even if it was fully specified because I don't have admin rights 
to any of the various SMTP servers used to send email for my domain.
5)Yahoo lacks credibility in the antispam community because of its bad 
reputation.

Here's someone's blog entry reviewing the proposal:
http://www.megacity.org/blog/archives/001288.php

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 07 Dec 2003 16:57:15 -0500

Philip Miller wrote:
[..]
> DK disadvantages: high burden of software implementation, requires 
> receipt of DATA before an authoritative check can be done
> 

The DATA problem can be solved with an ESMTP extension or some creative 
use of MAIL FROM AUTH extension.

BUT, I want you all to consider one more possibility - digital 
signatures implies digital keys, digital keys imply digital 
certificates. Another advantage of this approach is that the public key 
of the sending system can be signed by someone else. While DNS limits 
packet size (512 bytes for UDP), it is not unfeasible to have an 
external system with a database of digital keys signed by that 
authority. Sounds like a "Trusted Sender" approach that was proposed by 
Project Lumos.

Having the ability of someone else vouch for a domain, is another 
advantage of this approach (DK) over LMAP, although the possibility of 
spammers getting on the "approved" listed fraudently and centralized 
power problems, are issues.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"I ate your Web page. / Forgive me. It was juicy / And tart on my 
tongue." (MIT's 404 Message)
-------

---

From: Mark Baugher <[email-masked]>
Date: Sun, 07 Dec 2003 15:04:16 -0800

Alan,

At 07:26 AM 12/7/2003, Alan DeKok wrote:
<...>

>must change regularly, as spammers will quickly obtain it.

I don't know why you would assume this.

>The second
>done to get the key for each user, which is problematic.

A big problem with per-user private keys is that these
private keys are vulnerable when user machines are infected with
viruses.  I don't expect the mail operator's machines to be so
vulnerable.  Also, past experience has shown that most users hate
to use cryptographic technologies for email or anything else when
they have a choice.

>(Why not

This sounds like a very good approach from MTA(s)->MTA(r), but
what about the case of MTA(s)->MTA(i)->MTA(r), which is a rare
case that nonetheless needs to be supported?

Mark

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 08 Dec 2003 10:35:06 -0500

> I don't know why you would assume this.

  If every user has access to the private key to sign outgoing
messages, then spammers have access to it, too.  After all, spammers
can sign up for accounts at ISP's...

> viruses.

  That's really outside of the scope of the solution.

  However, having *signed* viruses means you're pretty sure whose
machine is infected.

>   I don't expect the mail operator's machines to be so vulnerable.
> Also, past experience has shown that most users hate to use
> cryptographic technologies for email or anything else when they have
> a choice.

  I thought the whole point of the solution was that users wouldn't
even know their messages were being signed.

> case that nonetheless needs to be supported?

  See the LMAP discussion document for ways to do this.

  Alan DeKok.

---

From: "Derek J. Balling" <[email-masked]>
Date: Mon, 8 Dec 2003 10:49:34 -0500

> I don't know why you would assume this.

If I am $BIGCORP with $BIGNUM of employees, there's going to be 
less-than-honorable employees, there's going to be disgruntled 
ex-employees. If the sender signs their own message then your company's 
keys WILL get out into the wild.

---

From: Mark Baugher <[email-masked]>
Date: Mon, 08 Dec 2003 08:41:36 -0800

>keys WILL get out into the wild.

I assumed that the MTA would have the private key and sign; not that the 
mail operator would hand our a *copy* of a public/private keypair to each 
sender.  I have never heard of such a thing. Sorry that I missed that 
aspect of the yahoo proposal, where did they say that?

Mark

---

From: "Derek J. Balling" <[email-masked]>
Date: Mon, 8 Dec 2003 11:49:18 -0500

On Dec 8, 2003, at 11:41 AM, Mark Baugher wrote:

>> ex-employees. If the sender signs their own message then your 
>> company's keys WILL get out into the wild.
>
> I assumed that the MTA would have the private key and sign; not that 
> the mail operator would hand our a *copy* of a public/private keypair 
> to each sender.  I have never heard of such a thing. Sorry that I 
> missed that aspect of the yahoo proposal, where did they say that?

There are two basic scenarios, both with flaws:

1.) The MTA signs the message:  This is problematic in the "traveling 
salesperson" type scenario, because often then cannot use their company 
mail server due to ISP filtering, etc.

2.) The MUA signs the message:  This yields one of two subproblems:
	2.a.) The MUA signs using a "per-user" key :  You now have to maintain 
in DNS several thousand keys for your large organizations
	2.b.) The MUA signs using a "domain-wide" key :  Every time you fire 
an employee you have to change the key or risk its misuse

Which of the three scenarios Yahoo intends to write into the spec is 
unknown, but all three are flawed. :-)

Cheers,
D

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 8 Dec 2003 17:07:15 +0000

> salesperson" type scenario, because often then cannot use their 
> company mail server due to ISP filtering, etc.
>
> 	2.a.) The MUA signs using a "per-user" key :  You now have to 
> maintain in DNS several thousand keys for your large organizations

or:

3) The signing is done by the MUA, but the key and crypto are all done 
by a separate entity, which I have called an MAA in the past.  The MUA 
authenticates to the MAA and sends a digest of the message, then gets a 
signature back to attach to the message.  The MAA may be physically 
colocated on the MTA, but is logically separate, uses a different 
protocol, and should avoid filtering by most ISPs.

This last scenario is what I suggested some time ago, and may yet be 
used as a component of the consent framework.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     [email-masked]
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.

---

From: Mark Baugher <[email-masked]>
Date: Mon, 08 Dec 2003 09:35:19 -0800

It's not clear to me what Yahoo is proposing since the descriptions I have 
read don't make much sense.  But the first question I have with any 
signature proposal is "what does the signature attest to?"  The signature 
might attest to the fact that the sender is legitimately sending from a 
particular address.  Or the signature might make no assertion about the 
address but only that the message originates from a particular key 
holder.  Or the signature might attest to the fact that the message 
originates from a particular mail operator who has a certain antispam policy.

Mark

At 09:07 AM 12/8/2003, Jonathan Morton wrote:
>>         2.b.) The MUA signs using a "domain-wide" key :  Every time you 
>> fire an employee you have to change the key or risk its misuse
>
>or:
>
>3) The signing is done by the MUA, but the key and crypto are all done by 
>a separate entity, which I have called an MAA in the past.  The MUA 
>This last scenario is what I suggested some time ago, and may yet be used 
>as a component of the consent framework.
>

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 08 Dec 2003 13:33:44 -0500

Mark Baugher <[email-masked]> wrote:
> signature proposal is "what does the signature attest to?"

  The signature is most likely done on a hash of the message body
and/or some headers from the envelope.

  What it *means* is another question entirely.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 08 Dec 2003 13:42:13 -0500

Yakov Shafranovich <[email-masked]> wrote:
> advantage of this approach (DK) over LMAP,

  Current blacklists can be viewed as a way of third parties vouching
for a domain.  The MTAMark proposal is similar.

  Though the various documents don't say so, there's nothing to stop
an MTA from looking up LMAP information in a third-party database,
too.  e.g.  "domain.com._lmap_.example.com", or
"4.3.2.1.domain.com._lmap_.example.com"

  Hmm... I'll add that to the discussion document as a possible method
of blacklisting domains which are known to host spammers.  Leveraging
the LMAP infrastructure for a domain-based blacklist just makes
sense...

  Alan DeKok.

---

From: David Maxwell <[email-masked]>
Date: Mon, 8 Dec 2003 13:50:18 -0500

> I don't know why you would assume this.

Probably because the mechanism hasn't been properly described in a
standards-track document - only as marketing material.

> Also, past experience has shown that most users hate

I would say instead that "most users hate to use technologies that
require effort".

Take SSL, which has been very widely adopted for transactions, as a
contradiction of your statement.

-- 
David Maxwell, [email-masked][email-masked] --> Unless you have a solution
when you tell them things like that, most people collapse into a gibbering, 
unthinking mass.  This is the same reason why you probably don't tell your 
boss about everything you read on BugTraq!    - Signal 11

---

From: Mark Baugher <[email-masked]>
Date: Mon, 08 Dec 2003 12:31:57 -0800

At 10:50 AM 12/8/2003, David Maxwell wrote:
<...>

>contradiction of your statement.

I'm referring to cases where the user actually has to sign something,
see http://www-2.cs.cmu.edu/~alma/johnny.pdf

Mark

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 08 Dec 2003 15:32:49 -0500

> unknown, but all three are flawed. :-)

Based on the information available to us, its the first scenario.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"And this too shall come to pass"
-------

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 08 Dec 2003 15:35:28 -0500

>   What it *means* is another question entirely.

The signature attests to the fact that the domain name or server from 
which the message originated, is not forged.

Yakov
-------

---

From: Philip Miller <[email-masked]>
Date: Mon, 08 Dec 2003 16:53:48 -0500

> the LMAP infrastructure for a domain-based blacklist just makes

Domain black-lists aren't particularly useful, because domains are cheap 
enough to register that spammers could send one load of spam from a given 
domain and then abandon it. If a spammer is stupid enough to stick around, 
or they have some pretense of legitimacy, then a blacklist could have some 
effect.

I thought the point was that white lists would become meaningful because 
people couldn't ride on someone else's good reputation, as they can now, and 
service providers could be held accountable for bad users sending mail 
within their domain.

Philip Miller

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 08 Dec 2003 17:11:20 -0500

> or they have some pretense of legitimacy, then a blacklist could have some 

  Blacklists can be updated during a spam run, which makes them
somewhat useful.  Also, the domain-based blacklists can be mined to
discover registrants (or registrars) who are associated with spam.

> service providers could be held accountable for bad users sending mail 

  LMAP isn't a whitelist.  It's a publication of consent information.

  Alan DeKok.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 8 Dec 2003 21:12:06 -0500

Keep in mind that this proposal will only work if the RFC specifications are
clarified due to one its central criteria.  Quoting Yahoo:

"If the receiving system can decrypt that private key with a public key
registered by the Internet's Domain Name System, then it will be assumed the
message is authentic. If it can't, the message is bounced back from whence
it came."

Therefore, like other proposals, if the bounce system is not reliable or
considered or interpreted as "optional", then there can only be one
assumption to be made; throw the message away.

In other words,  what will be the RFC guidelines on handling an unreliable
or incomplete bounce due to a failed decryption of a private key?

This still needs to be addressed.  You guys need to get going with this
because whether you understand this or not,  once YAHOO implement it,
software vendors, such as myself have no choice but to add support for it.

The way I view this or any proposal for that matter, is how will it fit into
the complete integrated mail system of our product, where will the
validation process take place?

For example, if YDK is to be deployed,  we might consider the implementation
to be placed at various points of the process.

In essence, the baseline compliance for this proposal is two MUA systems.
The middle ware is not really required.  However, trust increases as a 3rd
party component is involved in the validation process.

If a compliant MUA sender is used,  does the SMTP route have a role of
validating the key or simply pass it on to the final destination?

If a non-compliant MUA sender is used,  where in the SMTP process does it
add the private key? or does it?

Is there sufficient trust when the MUA receiver is not compliant and the
SENDER is validated by SMTP?

Does the POP3 server play a role?   Can an enhanced MUA POP3 client informed
the enhanced POP3 server to accept or not accept  non-validated YDK mail.

In short, once this or any system is put in place,  the users will
ultimately have to decide if the non-validated private key email should be
received by the system and that's something that needs to be programmed in
the SMTP software.

Private key or not,  vendors will have to offer the option to the admins on
how to handle mail that has yet in compliance with the system.

Quick example:

Confirmed YDK-Ready Mail Sender ->  SMTP passes on the mail.

Unconfirmed YDK-Ready Mail Sender ->  What happens with unreliable bounce?

No YDK header Mail Sender ->  Should SMTP confirm the sender (and how?) and
add the header?

It just seems to me that YDK works with widely deployed.  In the mean time,
the RFC needs to be updated to provided the control mechanisms when ANY NEW
SYSTEM is not confirmable or validated or used.

That all boils down to the bounce concept.

Bounce is possible - GREAT!
Bounce not possible - scratch your head.

---
Hector Santos, CTO
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com

---

From: Mark Baugher <[email-masked]>
Date: Mon, 08 Dec 2003 19:42:13 -0800

You're assuming that "system" means "MUA."  I did not assume that.  It is 
going to be hard to get going on this unless someone produces a meaningful 
and complete description.

It is also not clear how this plays with the Microsoft/AOL signing proposal 
that was also in the news.

Mark

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 08 Dec 2003 22:47:41 -0500

Mark Baugher wrote:
[..]
> It is also not clear how this plays with the Microsoft/AOL signing 
> proposal that was also in the news.
> 
[..]

Yahoo is part of the MSFT/AOL consortium, and it looks like it is the 
exact same proposal. The question is why Yahoo is marketing it all by 
itself...

Yakov
-------

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 08 Dec 2003 22:57:06 -0500

> or incomplete bounce due to a failed decryption of a private key?

I would not rely on their press releases or news stories based on their 
press releases until concrete specs for their proposal is released. I 
would assume their "bounce" here is referring to the industry standard 
way of doing bounces today, not anything esoteric.

[..]
> add the private key? or does it?

This proposal is specifically geared toward MTA signing messages, NOT 
MUAs. Trust between the MUAs and MTAs is accomplished via SMTP AUTH, and 
then the MTA signs the message before it is sent out. While it can be 
done through the MUAs, based on all information that is available to us, 
it is done on MTA level.

[..]

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
  "Why are both drug addicts and computer aficionados both called 
users?" (Clifford Stoll)
-------

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 8 Dec 2003 23:49:02 -0500

----- Original Message ----- 
From: "Yakov Shafranovich" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "Alan DeKok" <[email-masked]>; <[email-masked]>
Sent: Monday, December 08, 2003 10:57 PM
Subject: Re: [Asrg] 6. Proposals - DNS + PKI - Yahoo's "Domain Keys"

> press releases until concrete specs for their proposal is released.

duh. <g>

I presumed you are privy to any timeline information? Yahoo does say early
2004.  Doesn't give developers much time which is why I say that they are
basing this on a minimum compliance with MUAs only, like Outlook augmented
with their mail server.   Looks to me they are going to apply this to thier
moronic DATA level validation logic.

> I  would assume their "bounce" here is referring to the industry standard

Of course, no details. But any intelligent person can see any generic
concept applied here.

Whether its the MUA or MTA adding the private key, when that message come to
my SMTP server,  it sounds to me we are back to the original issues of MX,
PTR,  and Return Path validation concepts.  The burden is still on the SMTP
system to "determine" how much trust can be put into a transaction with or
without a private key.

No "KEY" from a YAHOO return path message:

         What steps should a SMTP server take?

Or is what YAHOO is telling the world that starting in 2004,  any message
that does not have a private key, should not be trusted?  Plain and simple?
Then as you mentioned, we are left with possible forgery issues.

The key to any successful technology is to tell the SMTP receiver not to
take any further action or minimum action on validating a transaction and it
needs to be done before DATA is received.

-- Hector

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 09 Dec 2003 00:10:26 -0500

Hector Santos wrote:
[..]
> I presumed you are privy to any time line information? Yahoo does say early
> 2004.
[..]

Nope, I am just as clueless about the time line as everyone else is.

[..]
[..]

I would venture to say that for domains that DO have the public key in 
DNS, any email originating from any other SMTP server with that domain 
as the "From" address inside the message, and not signed, can be 
rejected or given higher score in Spam Assassin. This of course would be 
a problem for users that use a different SMTP server to relay email, 
unless private keys are shared.

Therefore, this proposal would give immidaete benefit for those sites 
that utilize it, by reducing "joe jobs" forging that domain, and it will 
not require the entire Internet to adopt it on the sender's end unless 
they want to use it. This is similar to LMAP in that respect, but does 
present more overhead.

> needs to be done before DATA is received.

Since this proposal signs messages themselves that are transfered within 
the DATA command, this cannot be done before the DATA command. 
Therefore, unlike LMAP proposals it cannot be used at the MAIL FROM point.

Yakov
-------

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 09 Dec 2003 10:06:54 +0000

> they want to use it. This is similar to LMAP in that respect, but does 

It smells of magical belief to me. Just sprinkle on some public key fairy
dust and the problem just shrivels up. Ho hum. I can't really see what such
a scheme would offer which something like SPF/LMAP wouldn't.

I believe this is a "run it up the flagpole and see who salutes" kind of
experiment. I guess that people plant these stories so that they can (a)
see what happens to stock prices and (b) count the cheers vs. jeers.

--

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 09 Dec 2003 13:05:49 -0500

> a scheme would offer which something like SPF/LMAP wouldn't.

  Slightly lower administrative costs, perhaps.  Possibly better
ability to transit mailing lists.

  The drawback is you can't delegate authority like you can in LMAP.
You can't use permit '0/0' like you can in LMAP.

  The benefit is that admins don't have to contact the central DNS
server when outgoing MTA's change IP's.  Since in many, many, systems
those outgoing MTA's are also the MX's for a domain, that benefit is
near non-existent.

  Alan DeKok.

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 9 Dec 2003 20:36:52 +0100

> which the message originated, is not forged.

*lol*
I don't see any more security here as with a "paranoid" dns lookup.
If I do a reverse DNS lookup and get a name and do a lookup of the name
and get the IP I can assume#1 that it is correct.
   #1 with drawbacks as to DNS spoofing and DNS security.
Now, if the sending MTA has a signature on the message and I use DNS
to get the public key to verify the signature #1 from above still
applies. So the win for using PKI and not paranoid DNS lookups is zero.

If people don't get simple things right like a correct HELO hosts and DNS
for their mailservers, does anyone seriously believe they will get
PKI working? I surely don't believe that.
On one of our mailservers out of 143013 connections 66619 had
non-matching HELO hosts sent. That's about 47 percent. Any more
questions? Oh, and no, it's not only evil spammers:
  smtp5.wanadoo.fr:193.252.22.26	HELO mwinf0502.wanadoo.fr
  daedalus.apache.org:208.185.179.12	HELO mail.apache.org
  nlpproxy03.prodigy.net.mx:148.235.52.23 HELO smtp.prodigy.net.mx
  sc8-sf-sshgate.sourceforge.net:66.35.250.220 HELO sc8-sf-netmisc.sourceforge.net
  mxpool16.ebay.com:66.135.197.22	HELO mx40.sjc.ebay.com
	That's a kewl one: mx40.sjc.ebay.com -> 10.6.182.160
	leaking RFC addresses to the public Internet
  smtp05.web.de:217.72.192.209		HELO smtp.web.de
  datatracker.ietf.org:132.151.6.22	HELO optimus.ietf.org
  pluto3.daimler-benz.com:53.122.2.33	HELO daimler-benz.com

These few "well known names" were taken from a 10 minutes snapshot of the
mailer logfile.

But PKI always sounds kewl and wasn't it a nice press release for Yahoo
that made it all around the world?
Not too bad for some hot air, I'd say.

	\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: Yakov Shafranovich <[email-masked]>
Date: Tue, 09 Dec 2003 14:46:52 -0500

> applies. So the win for using PKI and not paranoid DNS lookups is zero.

Would there be a difference if the message is forwarded through a list, 
or is transfered via multiple MTAs?

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Be liberal in what you accept, and conservative in what you send" (Jon 
Postel)
-------

---

From: Mark Baugher <[email-masked]>
Date: Tue, 09 Dec 2003 12:13:20 -0800

Yakov,

At 11:46 AM 12/9/2003, Yakov Shafranovich wrote:
>Would there be a difference if the message is forwarded through a list, or 
>is transfered via multiple MTAs?

Is it fair to say that there may be many MTAs at the sender's domain, many 
at the receiver's domain, but there should at most be one MTA(i) in the 
forwarding path?  From the standpoint of mail signing, might the multiple 
MTAs at the sender be considered as a single MTA and similarly for the 
receiver?

Mark

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 9 Dec 2003 21:17:09 +0100

> or is transfered via multiple MTAs?

No. Because MTAs add headers and zillions of maillinglists add nice
(commercial/informational) trailers or remove attachments. Same for
large companies that think adding pseudo legal disclaimers makes any
difference.
All these destroy the structure of the email. These are problems that
e.g. PGP signers noticed long ago.

Now you can add headers to the sign. Which one would you add?
Date fields? How many mailservers have broken timezones. How many
mailservers are offline for 4 hours to 7 days? Add a special tag?
So what, I use this tag with my faked headers.

And the easiest solution:

a) get a Yahoo! account
b) login and send a email to  [email-masked]  with the exact message
   you want to spam with.
c) login as [email-masked] and save away the messages.
d) now you have a totally legal email signed by Yahoo! itself.
e) $ sendmail -ti [some 10000 addresses] < signed.mail

Now what problem does signing solve? Ok, it solves the problem for a lot
of people, but it makes it *really* easy to "legally" spam with messages
signed by public mail service providers and these are really easy to get ;-))

	\Maex

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 09 Dec 2003 15:26:22 -0500

Yakov Shafranovich <[email-masked]> wrote:
> Another difference here is that LMAP addresses MAIL FROM forgery in the 
> SMTP transaction, while DK addresses forgery in the mail headers and 
> email message itself.

  Which makes me wonder what STARTTLS was for.

  That's not entirely true...  STARTTLS encrypts a message hop by
hop, but you've got no guarantee that the hop you're talking to isn't
lying about the existence of previous hops.

  But for the vast majority of email, which flows directly from MTA to
MTA, DK is equivalent to using STARTTLS, with public keys looked up in
DNS.  Why sign the message, and then distribute it in the clear, when
you can instead distribute the message via an encrypted tunnel?

  But why use an encrypted tunnel or sign a message when it's being
delivered from your user, using your MX, to my MX, for my user?  The
audit trail is pretty straightforward there.

> What about if you use subkeys?

  Then the DK headers will have to include not just the domain
information, but which sub-key to use.  The extreme is that each user
will have their own sub-key, in which case spammers will have them,
and key maintenance become a nightmare.

  LMAP allows you to say that a machine is permitted to send mail,
without giving that machine permission to make those statements
itself.  DK gives a machine the ability to "hand-off" it's delegated
authority to third parties, without the knowledge, or consent, of the
originating authority.

  If you're going to have roaming users, you MUST use sub-keys, which
will be impossible to keep secure.  LMAP doesn't have this problem.

  Alan DeKok.

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 09 Dec 2003 15:06:58 -0500

Yakov
-------

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 09 Dec 2003 20:36:21 +0000

>   smtp5.wanadoo.fr:193.252.22.26	HELO mwinf0502.wanadoo.fr

dig mwinf0502.wanadoo.fr
;; ANSWER SECTION:
mwinf0502.wanadoo.fr.   86302   IN      CNAME   smtp5.wanadoo.fr.
smtp5.wanadoo.fr.       3486    IN      A       193.252.22.26

what's wrong with this? it's a FQDN. or is it that you think they shouldn't
use something with a CNAME? Is that not right?

problem is, IP 1---n Name, I think. And these are all "legit", which just
goes to show that "paranoid reverse lookups" don't work.

Or have I misunderstood?

--

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 9 Dec 2003 22:04:07 +0100

> use something with a CNAME? Is that not right?

Ok, my error.

But look at

  datatracker.ietf.org		-> 132.151.6.22
  22.6.151.132.in-addr.arpa	-> datatracker.ietf.org

  optimus.ietf.org 		-> 132.151.1.19
  19.1.151.132.in-addr.arpa.  	-> ietf.org.
  ietf.org.               	-> 132.151.1.19

> problem is, IP 1---n Name, I think. And these are all "legit", which just

No that is not the problem, there is no problem having multiple PTR
records. Look at e.g. pop.gmx.net:

pop.gmx.net			-> 213.165.64.20
20.64.165.213.in-addr.arpa.	->  mail.gmx.net.
20.64.165.213.in-addr.arpa.	->  pop.gmx.de.
20.64.165.213.in-addr.arpa.	->  pop.gmx.net.
20.64.165.213.in-addr.arpa.	->  imap.gmx.net.
20.64.165.213.in-addr.arpa.	->  mail.gmx.de.

> goes to show that "paranoid reverse lookups" don't work.

No you have exactly support my point of view ;-)
They can't get revDNS, forward DNS and HELO consistent. How should they
manage to get a PKI structure to work.

    \Maex

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 09 Dec 2003 16:13:14 -0500

Mark Baugher wrote:

>>>> The signature attests to the fact that the domain name or server 
>>>> from which the message originated, is not forged.
>>>
>>>
>>> *lol*
>> Would there be a difference if the message is forwarded through a 
>> list, or is transfered via multiple MTAs?
> 
> 
> Is it fair to say that there may be many MTAs at the sender's domain, 
> many at the receiver's domain, but there should at most be one MTA(i) in 
> the forwarding path?

If I understand correctly, that would mean that three MTAs are involved: 
sender's (s), intermediate(i) and receiver's(r). Therefore, LMAP will 
work for MTA(s) to MTA(i) connection, but will fail at MTA(i) to MTA(r) 
connection unless the sender's domain lists MTA(i) in LMAP. This 
presents a problem mainly for forwarding and is addressed in the LMAP 
discussion draft, section 3.4.

 > From the standpoint of mail signing, might the
> multiple MTAs at the sender be considered as a single MTA and similarly 
> for the receiver?

For DK, since the message itself is signed, forwarding is not as big of 
an issue, and how many MTAs are there does not matter, since they are 
not been authenticated anyway (unless some kind of a ESMTP extension is 
used, like Hector mentioned, or modified STARTTLS like Alan mentioned).

The point is that while LMAP does need some minor changes in forwarding, 
DK does not. BUT, as stated in the LMAP discussion draft, that is not a 
reason to choose one over the other, unless significant negative impact 
can be shown.

But then again, it is unclear what exactly is being done, since not too 
many details are available.

Yakov
-------

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 9 Dec 2003 13:51:14 -0500

----- Original Message ----- 
From: "Yakov Shafranovich" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 09, 2003 12:10 AM
Subject: Re: [Asrg] 6. Proposals - DNS + PKI - Yahoo's "Domain Keys"

> Therefore, unlike LMAP proposals it cannot be used at the MAIL FROM point.

Unless an ESMTP command is provided as part of the YDK specification for
possible use by supportive  systems.  Would that work?

-- Hector

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 09 Dec 2003 16:31:20 -0500

> e.g. PGP signers noticed long ago.

The same solutions that are used in PGP and S/MIME would be applied 
here, at least the message body itself. Details are still fuzzy...

> So what, I use this tag with my faked headers.

In the USEFOR WG in the IETF, the current draft (section 7.1) addresses 
a problem of signing headers in USENET control messages by including a 
special header with the digital signature, and signing only a select set 
of headers. I think that a similar approach would probably be used here, 
but I don't really know for sure. The USEFOR draft can be found at (see 
section 7.1):

http://www.ietf.org/internet-drafts/draft-ietf-usefor-article-12.txt

But your underlying objection is correct - headers get changed and added 
all the time. The question would be whether that will significantly 
affect this scheme and how to deal with it. Signing a select group of 
headers AND requiring MTAs that send signed messages to have those 
headers present might be one way of it.

> signed by public mail service providers and these are really easy to get ;-))

It is a valid objection - I believe in cryptology this would be called 
"a replay attack". One way of dealing with it is somehow authenticating 
the actual SMTP transaction, which brings us back to LMAP.

I think that the document that Alan was working on, addressing different 
points of the email infrastructure, might be very useful here. Also, it 
might perhaps be useful to create some kind of taxonomy of what we need 
to authenticate and different ways of doing so.

I think that based on all of the discussion here, it looks like all of 
the technical details have either not been fully thought through yet, 
and/or are not being publicly shared. So I guess we'll have to wait 
until they release the full technical specs for the proposal, hopefully 
addressing all of these issues.

Yakov
-------

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 09 Dec 2003 17:25:46 -0500

Markus Stumpf wrote:
> 
> Maybe there is anybody on this list with posting priviledges to the NANOG
> list and can ask for a contact to the Yahoo guys in the name of the ASRG?
> 

I will try to get in touch with them.

Yakov
-------

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 9 Dec 2003 23:15:54 +0100

> http://www.ietf.org/internet-drafts/draft-ietf-usefor-article-12.txt

I had a look at it.
The only place where they use signing is for control messages. This is
done as described in
   ftp://ftp.isc.org/pub/pgpcontrol/README.html
and it is IMHO not suitable for eMails, at least if they're not end to end.

> headers present might be one way of it.

What I see as problem is:

Imagine a header
   X-Signature: mail.example.com; sign=439KJHD9087KJKLHKJ7LKJJLK
Now I can check back with mail.example.com and validate the sign. Fine.
A spammer can now simply use that and it will be ok for everyone.
Now I want more security. Thus I need some variable token. One
possibility would be to use a date and give messages a lifetime.
   X-Signature: mail.example.com; date=20031209-23:06:17; sign=439KJHD9087KJKLHKJ7LKJJLK
Now the signature would be calculated using "mail.example.com" and the
varibale part "20031209-23:06:17". If it matches "439KJHD9087KJKLHKJ7LKJJLK"
the message will be accepted. A spammer can now simply use that very
line and it will be ok for everyone, at least until some expiration
date. However that has to be at least some days to compensate for
poorly configured hosts with wrong times or for message delays on relay
SMTP servers or the like. For a spammer it is rather easy to get a
valid line that is still valid for say 5 days: subscribe to any mailinglist
and the records are delivered right to your mailbox.

I do not believe that anything that depends on signing of headers only can
solve this problem. But without it the approach is useless.
And: it MUST contain the envelope sender address in the signature to
prevent sender forging.
There is no win to know that
   mail.example.com
correctly signed the fact that the email with a sender address of
[email-masked] was injected via
mail.example.com. There has to be a relation between mail.example.com
and [email-masked] that provides
some kind of authorization for mail.example.com.

> the actual SMTP transaction, which brings us back to LMAP.

Which is IMHO quite useless, as if the actual SMTP transaction is
between the first hop and the receiver it is clear to whom I am talking
(e.g. from DNS). If it is a multi-hop connection a replay attack is a
piece of cake.

	\Maex

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 9 Dec 2003 18:35:00 -0500

----- Original Message ----- 
From: "Yakov Shafranovich" <[email-masked]>
To: "Markus Stumpf" <[email-masked]>
> addressing all of these issues.

Right, however....

The problem is if  YAHOO is "truly" going to deploy on early 2004, that
really doesn't give anyone any time and more importantly it indicates they
(alliance?) have already "worked something out" and/or they are only truly
interested in stamping their own mail generated and going out their farm and
is telling the world, "hey, our mail headers will have private keys and
whoever supports it will be able to authenticate our mail."   However, what
they are not saying is that HOW that is done and if this going to be
deployed within 1-2 months, they MUST have some arrangement with AOL,
Microsoft and Earthlink.

Worst case paranoid scenario:  In time, once the public hollering quiets
down,  the system is proven to work with the "Alliance."  In the name of
security, the specification is proprietary is only given to certified mail
server developers under a NDA.

Anyway, with all that aside.

It seems to me that this Yahoo proposal is strictly designed around their
DATA validation methodology which in my opinion, minimized its adoption or
deployment effectiveness.  (Which they don't care as long the 4 sisters are
together on it).

Technically,  any private key concept must be applied with a 3+ tier system.
While only 2 end points is all that is required at a minimum,  the trust is
magnified when one or more independent middle wares validates the key during
the route of the message.

This can be illustrated with a trust value table:

Each mail system have different designs, but in general, they have these
components:

    - MUA: Mail Creator
    - MUA: SMTP Sender
    - MTA: SMTP Receiver (can be multiple routes)
    - MTA: SMTP Router (final destination route)
    - MTA: Mail Gateway (final destination storage)
    - MUA: POP3 Client
    - MUA: Mail Reader

It is conceivable at each of these components may be "involved" in the key
validation, including the POP3 server.

Why?

If this system is deployed, application developers can offer new options to
the user, i.e, Outlook mail pickup options:

        [X] Rejected all non-YDK validated mail
        [X] Accept YDK mail with trust value equal or greater than: 8

Give each component a sequential trust value, 1 through 7.   Each component
can add a missing key or validate an existing one.

The trust of a transaction is the summation of the compliant components.

At a minimum, the endpoints yield a trust value of 8 (1+7).
At a maximum, with all components complying,the highest trust value is 28
(1+2+3+4+5+6+7+8)

I don't wish to draw out the total scenarios and trust values, but I wish to
point how I may use to determine where I would add a key to gain a high
trust with minimum compliance.  In this case, it would be the POP3 server,
the final MUA plus one other component.  In our design, since the gateway is
central for all mail formats coming into the system, it may be the best spot
for us. So:

    - MTA: Mail Gateway (final destination storage)
    - MUA: POP3 Client
    - MUA: Mail Reader

with a trust of 18 (5+6+7).

This tells me this is better than having

    - MUA: SMTP Sender
    - MUA: POP3 Client
    - MUA: Mail Reader

with a trust of 15 (2+6+7).

This works for us, because we mail also have:

    - MTA: Mail Gateway (final destination storage)
    - Web Mail Server
    - MUA: Mail Reader (Browser)

or

    - MTA: Mail Gateway (final destination storage)
    - Telnet Mail Server
    - MUA: Mail Reader (Telnet client)

or

    - MTA: Mail Gateway (final destination storage)
    - GUI Mail Server
    - MUA: Mail Reader (GUI client)

etc, etc.

In other words, for YDK, I see this:

1) It assumes mail is received (DATA state).

2) For some systems, it may be best to apply it only at the final
destination component and this may not be a SMTP system but simply a RFC822
compliant system.

3) And that this may be best applied at the POP3 server (mail pickup) level
because it offers end-users new options at the application level.

I believe that any proposal that has its basis with mail content validity
vs. mail sender validity, is not something SMTP should be involved with.
(SMTP should strictly deal with the validation of the transport, like LMAP,
SAP and others.) While SMTP can help the process (such asp non-RFC822 MUA
systems), a proposal that will not have full deployment is simply beating a
dead horse.  With minimum deployment,  this YDK proposal works best at the
endpoints plus the pop3 server which seems to be exactly what YAHOO is doing
with an early 2004 release.

-- Hector

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 10 Dec 2003 01:21:11 +0100

> server developers under a NDA.

Perfect. I can't wait to add
    @aol.*
    @yahoo.*
    @msn.*
    @hotmail.*
    ...
to the badmailfrompatterns of our mailservers and get rid of all that crap
that either originates from them or fakes their domains.
And I am sure a lot of others are, too. They're using a proprietary
mail system that I can't send messages to, so why should I accept
message I can't reply to?

The implication is that AOL can spam yahoo and MSN and vice versa but
no one else. This will bring AOL back to the early 90s (or was it later
80s) when they were a large Mailbox. After that they'll be one again, as
will Yahoo and MSN. Where's your problem?

	\Maex

---

From: Mark Baugher <[email-masked]>
Date: Tue, 09 Dec 2003 16:28:05 -0800

At 02:15 PM 12/9/2003, Markus Stumpf wrote:
<...>
I'm not making a case that signing is better or worse that
LMAP, SPF, or similar approaches.  I really don't know so
there is no hidden polemic here.  I just have some questions
and comments.

>A spammer can now simply use that and it will be ok for everyone.

A clarification...

           +---------------+             +---------------+
           | UA.o -> MTA.o | -> MTA.i -> | MTA.r -> UA.r |
           +---------------+             +---------------+

Are you saying that MTA.o signed it and a spammer captured
the message and resent it?  Was it resent from MTA.o or from
some other domain or does this not matter?

If the spammer sends from MTA.o, then wouldn't we expect MTA.o
to have a policy to not forward mail that it had previously
signed?

If it comes from some MTA.x then a legitimate MTA.x might
reasonably have a policy of not forwarding mail signed by
some MTA.o unless (1) it has some MTA.i relationship
with MTA.o, which will rarely be the case, and
(2) it was in fact received from MTA.o.

If MTA.x is not legit, then won't MTA.r make a determination
on the validity of the message based on the trust it places
in the signature of MTA.x and not MTA.o?

Mark

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 10 Dec 2003 02:20:41 +0100

> A clarification...

You don't need to capture.
The problem I addressed is "what to sign" to make it impossible to steal
the signing and use it in another context.
E.g. the message to the list I am replying to has headers:

Received: from mbaugher-w2k07.cisco.com (sjc-vpn3-38.cisco.com [10.21.64.38])
        by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hBA0S6iO027174;
        Tue, 9 Dec 2003 16:28:07 -0800 (PST)
Message-Id: <[email-masked]>

Both header lines are (or should be and probably are) unique. So you now
could use them, build a checksum, sign it with your private key and get
something like 'JK807JK8JK90KLKL'. Now you add a Header like
   X-Signature: sj-core-4.cisco.com; sign='JK807JK8JK90KLKL'
I can now (as the recipient) lookup your public key and validate,
whether the above two lines match the signature in the X-Signature:
line. So far so good.

But now, what stops a spammer from copying the two lines and the
X-Signature line and create a new email useing the stolen headers
like:

How would you know that the message NOT really originated (or was sent
via) sj-core-4.cisco.com?

As a lot of software modifies/replaces/deletes both the message headers
and the message bodies you can't simply base your digest and signature
on this information.

> to have a policy to not forward mail that it had previously

No. Why?
If I get an eMail from a friend with an address at a public mail service
provider (aka freemail) and think it is funny, why should it not be
possible to bounce the message on to another friend at the same freemail
provider as the original sender? Or think of simple addresslists ...
   cat >> .forward   (for [email-masked])
   [email-masked]
   [email-masked]
   [email-masked]
Now [email-masked] sends mail to [email-masked] and the mail will
go back to the originating system to [email-masked].

> with MTA.o, which will rarely be the case, and

How can you detect relationships between MTA.x and MTA.i? What do you
mean with relationships between MTA.x and MTA.i?

> (2) it was in fact received from MTA.o.

To determine this is the problem ;-)

> in the signature of MTA.x and not MTA.o?

How do you determine that "MTA.x is not legit"?
Is  dsl081-084-010.lax1.dsl.speakeasy.net  [64.81.84.10]  legit if it
can provide a certificate? What must be the object of the certificate
(sorry I don't know the correct english word, what is it that is
certified? Is it the name? is it the IP address?) If it tries to inject
an email with an envelope sender [email-masked] and a recipient address
in your domain and it has a legit certificate (whatever that means)
how can you determine if the message really originated at MTA.o?

Yahoo's answer would be "look at the signature", but we've seen above
that it is hard to put a signature in a email and making it secure
and not stealable.

	\Maex

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 10 Dec 2003 00:51:55 -0500

[..]
> and the records are delivered right to your mailbox.

Lets say that a spammer does do a replay attack. Wouldn't signing the 
message (body and headers) force the spammers to be able to send 
identical spams if they want them to appear to come from that domain? 
Wouldn't that also mean that systems that rely on identical spam content 
such as DCC, would be able to catch the spams easier?

What it seems to me now, is that this proposal is not meant to be by 
itself, it rather addresses only certain points and tricks that spammers 
use. But cutting away the ability to joe-job a site unless you want to 
send all of your messages as identical, would definatly help some what.

Yakov
-------

---

From: Fridrik Skulason <[email-masked]>
Date: Wed, 10 Dec 2003 09:58:21 +0000

> send all of your messages as identical, would definatly help some what.

But it doesn't even do that - a "replay" does not have to involve just
a single message, but rather a large number of similar messages.

Consider this scenario:

   A spammer gets an account at yahoo.com and sends (to some throwaway.com
   address) a few thousand almost identical messages, each of which gets
   properly signed by Yahoo.

   Then throwaway.com starts spamming those messages, with Yahoo's
   signature, and the headers faked to make it look like the message
   comes from Yahoo ... sure, the IP number does not belong to Yahoo,
   but unless you have something like LMAP you are out of luck in that
   respect.

   Of course the spammer takes certain precautions, such as not sending 
   the same variant of the message twice to the same domain - thus 
   trying to reduce the chance of anyone noticing two *identical* 
   messages.

Or am I missing something?

-- 
Fridrik Skulason   Frisk Software International   phone: +354-540-7400
Author of F-PROT   E-mail: [email-masked]       fax:   +354-540-7401

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 10 Dec 2003 17:43:09 -0500

> Or am I missing something?

A distributed spam detection system such as DCC 
(http://www.rhyolite.com/anti-spam/dcc/) works across multiple domains. 
Therefore is the spammer sends an identical message to more than one 
domain, it can be detected.

In any case we will have to wait until they release their full 
specifications.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Some lies are easier to believe than the truth" (Dune)
-------

---

From: Mark Baugher <[email-masked]>
Date: Wed, 10 Dec 2003 17:05:07 -0800

Markus,

At 05:20 PM 12/9/2003, Markus Stumpf wrote:
>Received: from sj-core-4.cisco.com
>         by mail.example.net with ESMTP id 1234567890;
>         Wed, 10 Dec 02:02:32 +0100 (CEST)
>X-Signature: mail.example.com; sign='908865KJGLSD0987'

It would not verify if the signature design was secure.  That is,
one should not sign a piece of the message that could be cut and
pasted in this way.  I have not seen anything about the signing
proposal to suggest that they were doing this or even signing SMTP
trace record.

So yes, the problem you describe is a problem that's caused by a
poor signature design.

>and the message bodies you can't simply base your digest and signature

What gets signed is an open question.  This does not strike me as
an insurmountable problem.

>go back to the originating system to [email-masked].

I think of each message sent as a separate mail transaction that will
have a separate signature applied by the mail submission agent.

>How can you detect relationships between MTA.x and MTA.i?

You (i.e. MTA.r) do not need to detect this relationship.  What I
wrote above is "a legitimate MTA.x might reasonably have a
policy of not forwarding mail from MTA.o unless 1) it has some
MTA.i relationship with MTA.o, which will rarely be the case..."

>What do you

I did not write about a relationship between MTA.x and MTA.i.
I'm apparently being unclear.  Please forget about MTA.x and let
me try this again.  I assume that in the vast majority of cases
there is no need for an MTA.i.  I assume that the MTA.i is required
where dialup is needed, in countries where online connectivity
is intermittent, or between planets, etc.  I am also assuming
that when MTA.i provides such a service to an MTA.o, then THEY
have a relationship.  Please correct me if I'm wrong.

>To determine this is the problem ;-)

If MTA.o and MTA.r both do signing and verification, then
they have credentials (keys) to establish a TLS connection.

>How do you determine that "MTA.x is not legit"?

You (MTA.r) don't need to determine this.  In my note I was breaking
down the problem by cases, e.g. A or not A.

>can provide a certificate?

No.  Anyone can get a certificate.  But if it has a certificate that
MTA.r has issued, signed, or otherwise authorized then
I would expect that it would consider MTA.o to be "legitimate."
There would need to be some ceremony or procedure in place in which
people are involved - kind of like a key-signing party.  What I don't
like about the signing approach is that good security technology
requires trained personnel and this can be expensive.  What
might make this cheaper is the fact that the result of a temporary
security breach in antispam is not as serious as, say, accepting a
bad route in BGP.

>What must be the object of the certificate
>certified? Is it the name? is it the IP address?)

That's a good question.  I'm an SPKI bigot and don't think we necessarily
need a public key bound to a name.  The public key itself can serve as
the identifier.  But Yakov said that the key attests to the fact that
MTA.o is authorized to use an address.  Some would probably see use of
an X.509 cert that binds a public key to a domain name as being
the way to go.

>If it tries to inject

LMAP :?)

>that it is hard to put a signature in a email and making it secure

I think it can be done and you could reasonably ask me to prove it.
That would lead to a long thread on MTA signing, which I don't think
is germane to this list.  Instead, it would be better to agree to
disagree.

cheers, Mark

---

From: Jim Fenton <[email-masked]>
Date: Fri, 12 Dec 2003 08:36:15 -0800

>e.g. PGP signers noticed long ago.

If the mailing list wants to modify the body of the message or a signed header, the mailing list software needs to check the signature of the message before forwarding it, and replace the signature with one valid for the mailing list itself, after adding whatever it wanted to add. The signature will need to be associated with the envelope-from address, rather than the from address.

-Jim

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 17 Dec 2003 21:50:57 +0100

> So yes, the problem you describe is a problem that's caused by a

The problem is that I yet have to see a signature design that will work
and that will not be broken by a sufficiently large number of mailservers/
features out there.

> an insurmountable problem.

:-) IMHO exactly this is the problem that hasn't been solved yet.

> have a separate signature applied by the mail submission agent.

What is the advantage then?
I know who I am talking to directly. So the sending MTA doesn't need the
hassle to sign the message. The MTAs could simply use TLS or a key
exchange. The advantage of the signing is that I - as the receiver -
can validate the signing of the original sender or - that would be fine -
of all intermediate hosts.
Other than that it's pretty worthless, IMHO.

	\Maex

---

From: Mark Baugher <[email-masked]>
Date: Sat, 20 Dec 2003 07:37:26 -0800

Markus,

>and that will not be broken by a sufficiently large number of mailservers/

There are many alternative signature designs.  One may sign the actual
mail message, or the design could be to "sign" the TLS connection between
mail agents, for example.  Furthermore, the signature could attest
to the address or the signature could attest to the fact that a
particular mail operator forwarded the mail.  Here are four alternatives
and there may be more.

Which of these are you thinking of or are you thinking of all of them?

>:-) IMHO exactly this is the problem that hasn't been solved yet.

Before going further down this path.  Is the problem that you address
concerned with adding a signature to the message and having that
message re-written in ways to invalidate the signature?

Cheers, Mark