signing all outbound email

Has anyone created hooks in MTAs so that they automagically
sign outbound email, so that you can stop forgery spam via a
SRV DNS record?
-- 
"If you're not part of the solution, you're part of
the precipitate."
Unix "guru" for rent or hire -><- http://www.li
ghtconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098
0C55 1484

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

On 4 Sep 2006, at 4:13 AM, Travis H. wrote:

> Has anyone created hooks in MTAs so that they
automagically
> sign outbound email, so that you can stop forgery spam
via a
> SRV DNS record?

Take a look at DKIM (Domain Keys Identified Mail) which does
 
precisely that. There is an IETF working group for it, and
it is  
presently being deployed by people like Yahoo, Google, and
others.  
There's support for it in SpamAssassin as well as a
Sendmail milter.

Go look at <http://www.dkim.org/>
for many more details.

	Jon


------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

Jon Callas wrote:
> 
> On 4 Sep 2006, at 4:13 AM, Travis H. wrote:
> 
>> Has anyone created hooks in MTAs so that they
automagically
[...]
> Go look at <http://www.dkim.org/>
for many more details.

This approach is MTA-to-MTA... if you want something more
MTA-to-MUA,
then you can take a look at this:

http://www.spri
ngerlink.com/content/qt219462521k1113/?p=0f0727071a8245b7b57
74b729461322e&pi=0

Cheers,
Max

At 11:40 AM +0200 9/5/06, Massimiliano Pala wrote:
>Jon Callas wrote:
>>
>>On 4 Sep 2006, at 4:13 AM, Travis H. wrote:
>>
>>>Has anyone created hooks in MTAs so that they
automagically
>[...]
>>Go look at <http://www.dkim.org/>
for many more details.
>
>This approach is MTA-to-MTA...

No, it's not. The receiving MTA *and/or* MUA can verify
signatures. 
That is clearly covered in the protocol document.

--Paul Hoffman, Director
--VPN Consortium

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

On 5 Sep 2006, at 2:40 AM, Massimiliano Pala wrote:

> This approach is MTA-to-MTA... if you want something
more MTA-to- 
> MUA....

Not precisely. It is *primarily* MTA-to-MTA, for a number of
very  
good reasons, like privacy. However, a number of people will
be  
implementing DKIM verification in the MUA, including Yahoo!.
(I've  
seen UI mockups, but they may have it shipping for all I
know.) The  
protocol itself is completely agnostic on that. The
signature travels  
with the message and the signing key is in the network. As
long as  
you have both, you can verify the signatures.

	Jon


------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

Jon Callas wrote:

> 
> [... about DKIM ...] The signature travels  with the
message and 
> the signing key is in the network. As long as  you have
both, you can 
> verify the signatures.
> 

"the signing key is in the network" -->
Indeed. The public signature key 
is stored in the DNS.

DKIM might be the first widely deployed application to use
the DNS as 
the preferred means of distributing public keys.

*Authenticated* public key distribution would need an
upgrade of the DNS 
with DNSSEC deployment.

Perhaps it is time for discussion groups like this one to
take a look at 
DNSSEC (RFC4033 / RFC4034 / RFC4035) and review its security
principles, 
trust model, deployment challenges, HMI (Human Machine
Interaction) 
aspects, etc.

Look at 
http://www.circleid.com/posts/dnssec
_deployment_and_dns_security_extensions/ 
or query your favorite web search engine with
"DNSSEC".

Good reading.

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreauconnotech.com


------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

Jon Callas wrote:
> Take a look at DKIM (Domain Keys Identified Mail) which
does precisely 
> that. There is an IETF working group for it, and it is
presently being 
> deployed by people like Yahoo, Google, and others.
There's support for 
> it in SpamAssassin as well as a Sendmail milter.

recently published IETF RFC

... from my IETF RFC index
http://www.g
arlic.com/~lynn/rfcietff.htm

4686 I
  Analysis of Threats Motivating DomainKeys Identified Mail
(DKIM), Fenton J., 2006/09/26 (29pp)    
  (.txt=70382) (Refs 1939, 2821, 2822, 3501, 4033) (was
draft-ietf-dkim-threats-03.txt)

from the introduction:

The DomainKeys Identified Mail (DKIM) protocol is being
specified by
the IETF DKIM Working Group.  The DKIM protocol defines a
mechanism
by which email messages can be cryptographically signed,
permitting a
signing domain to claim responsibility for the use of a
given email
address.  Message recipients can verify the signature by
querying the
signer's domain directly to retrieve the appropriate public
key, and
thereby confirm that the message was attested to by a party
in
possession of the private key for the signing domain.  This
document
addresses threats relative to two works in progress by the
DKIM
Working Group, the DKIM signature specification [DKIM-BASE]
and DKIM
Sender Signing Practices [DKIM-SSP].

... snip ...

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

Lynn Wheeler wrote:
 > recently published IETF RFC
 >
 > ... from my IETF RFC index
 > http://www.g
arlic.com/~lynn/rfcietff.htm
 >
 > 4686 I
 >  Analysis of Threats Motivating DomainKeys Identified
 >  Mail (DKIM),
 > Fenton J., 2006/09/26 (29pp)     (.txt=70382) (Refs
 > 1939, 2821, 2822, 3501, 4033) (was
 > draft-ietf-dkim-threats-03.txt)
 >
 > from the introduction:
 >
 > The DomainKeys Identified Mail (DKIM) protocol is
 > being specified by the IETF DKIM Working Group.  The
 > DKIM protocol defines a mechanism by which email
 > messages can be cryptographically signed, permitting a
 > signing domain to claim responsibility for the use of
 > a given email address.  Message recipients can verify
 > the signature by querying the signer's domain directly
 > to retrieve the appropriate public key, and thereby
 > confirm that the message was attested to by a party in
 > possession of the private key for the signing domain.
 > This document addresses threats relative to two works
 > in progress by the DKIM Working Group, the DKIM
 > signature specification [DKIM-BASE] and DKIM Sender
 > Signing Practices [DKIM-SSP].

In order for this to actually be any use, the recipient
needs to verify the signature and do something on the
basis of that signature - presumably whitelist email
that genuinely comes from well known domains.

Unfortunately, the MTA cannot reliably do something - if
it drops unsigned mail that is fairly disastrous, and
the MUA cannot reliably check signatures, since the MTA
is apt to mess the signatures up.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

James A. Donald wrote:
> In order for this to actually be any use, the recipient
> needs to verify the signature and do something on the
> basis of that signature - presumably whitelist email
> that genuinely comes from well known domains.
> 
> Unfortunately, the MTA cannot reliably do something -
if
> it drops unsigned mail that is fairly disastrous, and
> the MUA cannot reliably check signatures, since the MTA
> is apt to mess the signatures up.

so what if an isp only signs email where the origin address
is the same
as the claimed email "from" address.

then email that claims to be from such an isp, that isn't
signed, might assumed to be impersonation.

and any "abuse" reports to the isp ...where the
email has been signed
... should at least trace back to the correct originating
account.

ISPs could do ingress filtering where they only process
incoming email
from their customers ... where the origin address matches
the email
"from" address ... which would eliminate their
customers from
impersonating other addresses ... but doesn't preclude
customers at
non-participating ISPs from impersonating their customers.

ISPs could also start to quarentine unsigned email that
claims to have
originated from ISPs that are known to sign email.

it might be considered to be small step up from ssl domain
name digital certificates ... where the browser checks that
the domain name in the URL is the same as the URL in the
certificate. the issue in the ssl domain name scenario is
some common use where the user has little or no awareness
of the domain name in the URL  .... so the fact that the
actual domain name matches the domain name in the
certificate
may bring little additional benefit.

lots of past collected posts mentioning ssl domain name
certificates ... some of the posts mentioning merchant
comfort digital certificates
ht
tp://www.garlic.com/~lynn/subpubkey.html#sslcert

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

  James A. Donald wrote:
 > > In order for [DKIM] to actually be any use, the
 > > recipient needs to verify the signature and do
 > > something on the basis of that signature -
 > > presumably whitelist email that genuinely comes
from
 > > well known domains.
 > >
 > > Unfortunately, the MTA cannot reliably do
something
 > > - if it drops unsigned mail that is fairly
 > > disastrous, and the MUA cannot reliably check
 > > signatures, since the MTA is apt to mess the
 > > signatures up.

Anne & Lynn Wheeler wrote:
 > so what if an isp only signs email where the origin
 > address is the same as the claimed email
"from"
 > address.
 >
 > then email that claims to be from such an isp, that
 > isn't signed, might assumed to be impersonation.

Then you get into the same problem as with SPF.

Obviously the problem can be solved, it is not even hard
to solve, but the solutions we have now do not actually
work.

 > ISPs could do ingress filtering where they only
 > process incoming email from their customers ...

There are lots of excellent, and reasonably simple
solutions, that work if everyone alters their behavior
except for a few wicked malefactors, and all software is
fixed up so that it works with the new solutions, but
the solutions that are actually under way right now do
not work well when there is a mix of old and new
software, and old and new practices.

In order to get to the end state where email is secure,
each step along the path has to be in the interests of
the individual making the change.  It is easy to imagine
an end state that is better than what we have now.  The
trouble is that part way to the end state also has to be
better than what we have now.

We need a solution that is good for the individual to
implement right now, and also solves the problem if most
people implements it - has increasing network effects.

 > ISPs could also start to quarentine unsigned email
 > that claims to have originated from ISPs that are
 > known to sign email.

But, in practice, domains cannot control the behavior of
people who legitimately use that email domain name, so
people do not in practice follow the sender policy
framework.  If an ISP drops mail that violates another
ISP's sender policy framework, it is intolerable,
because most of the mail dropped will be legitimate.
Filtering has to be done client side, where the client
can judge what is good for him, what works for him.

The solution is for the recipient MTA to add all the
authenticity information that it can get into the mail
headers, and for the client side filtering software to
pay attention to these MTA headers - but that is not the
solution we have.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

  James A. Donald wrote:
> > > In order for [DKIM] to actually be any use,
...

>Anne & Lynn Wheeler wrote:
> > so what if an isp only signs email where ...

etc, etc.

You know, we've already had all these arguments on the DKIM
mailing
list about a hundred times.  

It's true, just about everything that is wrong with DKIM is
also wrong
with every other signature scheme.  The salient difference
is that
DKIM sets its sights lower and is designed to be more easily
deployable so there is more of a chance that it can break
out of the
ghetto where all the existing message signature schems
languish, and
at least increase the amount of mail that peoples' known
correspondents have signed.  Despite a great deal of
misreporting and
wishful thinking, we do know that it is neither a magic
bullet against
spam nor against phishing.

Rather than having the same old arguments yet again, how
about reading
the list archives linked from
http://www
.mipassoc.org/dkim/ietf-dkim.htm and at least argue
about
something different?

Regards,
John Levine, johnliecc.com, Primary Perpetrator of "The
Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom,
revealingly.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com