As I pointed out in an earlier message, there are problems with
the end to end security model when you have a link by link
security problem.
S/MIME is great for many applications but it does have limitations.
In particular we have customers who want to be able to add signature
disclaimers onto outgoing mails. Also they regularly block outgoing
encrypted email because that would be a regulatory issue and so on.
So SSL is actually better suited for many applications, especially
here where the hop that matters is the hop across the Internet where
dragons be.
But SSL does not work for all people - see the complaints of Kieth
Moore.
Phill
-----Original Message-----
From: Ken Hirsch [mailto:hirschk(_at_)labcorp(_dot_)com]
Sent: Monday, April 28, 2003 4:58 PM
To: Kee Hinckley
Cc: asrg(_at_)ietf(_dot_)org
Subject: Re: [Asrg] Proposal for transition to authenticated email
Kee Hinckley wrote:
At 2:15 PM -0400 4/28/03, Ken Hirsch wrote:
The cryptographic signatures can be on each message (S/MIME) or can
be for an entire session (HTTP-over-TLS). But the latter is only
acceptable if no further forwarding of messages will occur.
Define forwarding? Mailing list? I hit Forward in the
MUA? I'm not
sure what you mean.
This is a good question. If you use S/MIME, then the authentication
will be carried forward no matter what, but generally it is
the outermost
signature that should be used for anti-spam authentication.
If you hit
Forward in the MUA, then you (the forwarder) are the sender
and you are
responsible for the message. For a mailing list it's not clear. Some
thought would need to go in to how a mail-forwarding service
should work
with this.
My thinking is that SMTP-over-TLS is less expensive, because
certificates will be checked fewer times and encryption/decryption can
be hardware-accelerated. I think that the vast majority of emails are
directly from the originator's MTA to the recipient's MTA and
you should
be able to use session authentication, but it may be difficult in
practice to know when it is applicable.
session) must be from a recognized Certificate Authority (CA), must
be "expensive enough" that spammers cannot easily get many of them,
What do you think that is? I can get a web cert for @$100 US/yr.
(Probably cheaper.) Is that enough of a cost to keep spammers out?
I doubt a certificate authority could manage to police the system as
you indicate without significantly increasing that price.
That may well be. Note that the certificate authority is not the only
one doing policing, though. If messages are authenticated, it is much
easier to detect abuse and filter it. Even at $100 per cert, if abuse
is detected after 10,000 messages, that's $.01 per message,
which may be
enough to dissuade the abuse. Plus the certificate authority
will have
at least some identifying and financial information to prevent the
abuser from acting again.
The certs should be expensive. One per ISP is enough, so
$1000, $5000, or
even $10,000 would not be unreasonable. I can hear the small
ISPs screaming
now, but they could contract out SMTP service.
- no sending allowed to harvested emails
It's not clear how you enforce this, or deal with an
expensive dispute
process.
People already create fake addresses to detect harvesters.
If a sender
uses these then the burden would be on him to show that he
was tricked.
This should promote good practices (double opt-in, logging of
web-based
subscriptions, etc.) to avoid penalties.
- double opt-in required for mailing lists.
I think the existing commercial list providers have made it
clear that
they will not do confirmed opt-in. And even on this list people have
pointed out that confirmed opt-in loses legitimate subscribers.
Perhaps if there were MUA support for it, but otherwise I don't think
you'll get sign on.
They may well object, but I'm under no obligation to accept them,
either. My proposal is not to make any of these policies
mandatory, but
only to mandate authentication and truth-in-labeling.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg