Subject: RE: [Asrg] Proposal for transition to authenticated email

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 28 Apr 2003 15:06:13 -0700

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:[email-masked]]
> Sent: Monday, April 28, 2003 4:58 PM
> To: Kee Hinckley
> Cc: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
> 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 28 Apr 2003 15:21:07 -0700

There is another approach, go back to a PEM like scheme in parallel
with S/MIME. That can provide a robust identification without impact
on the message that impacts the end user (S/MIME is unfortunately not
going to work for Eudora users).

There can even be enforcement here, we could rent a trusted box
to the ISP that implements the Velocity Indicator technology and
only applies the authentication mark if the message is within policy.

It also means that different customers for a bulk sender could have 
different tags attached. Consider the case where the mailing list ID
is bound into the authentication token. The problem at the moment is
that the recourse hits the wrong party, the bulk sender not the mailing
list owner.

We are more likely to get compliance if we give people the tools to 
enforce it.

		Phill

> From: Vernon Schryver [mailto:[email-masked]]
> Sent: Monday, April 28, 2003 6:01 PM
> To: [email-masked]
> > From: "Ken Hirsch" <[email-masked]>
> 
> > ...
> > be hardware-accelerated. 
> S/MIME and other mechanisms could also use hardware.
> 
> I advocate the use of SMTP-TLS, but it has a major defect for
> authenticating mail.  It only authenticates one MTA to another, or
> in some cases an MUA to an MTA or an MTA to an MUA.  It does not
> authenticate the sender of the mail message itself.
> 
> >                           I think that the vast majority of 
> emails are
> > directly from the originator's MTA to the recipient's MTA ...
> 
> That is true only in very simple cases.  If that were true, then
> you could filter spam by rejecting all mail with more than one
> Received header.  Please consider "smart host," "mail firewall,"
> "bastion host," and "MX secondary."
> 
> 
> > enough to dissuade the abuse.  Plus the certificate 
> authority will have
> > ...
> If any of that were true, then it would be equally true of ISPs.
> Every SMTP message carries a practically unforgeable token identifying
> and authenticating the previous hop ISP.  If certificate authorities
> could be trusted to police customers that spend $100/year for a
> certificate, then ISPs could be trusted to police customers that spend
> $240/year for ISP service.
> 
> 
> Vernon Schryver    [email-masked]

---

From: Scott Nelson <[email-masked]>
Date: Mon, 28 Apr 2003 23:35:09 -0700

At 12:46 AM 4/29/03 -0400, Ken Hirsch wrote:
>From: "Vernon Schryver" <[email-masked]>
>And that is all that is necessary.  
>I don't think that authenticating the actual sender is practical.  
>In order for sender authentication to be common it has to be
>inexpensive and convenient.
>

I think it depends on what you mean by "authenticating".
If, for example, you wanted to assure that MAIL FROM:<[email-masked]>
was really from someone who could read email sent to [email-masked],
then all you need to do is send an authentication token to [email-masked]
and require they use it in all future emails. Simple Challenge/response 
via email.

Hmm... you might even be able to layer that on top of the existing
SMTP protocol with something similar to the TMDA method by placing
the tokens in the to and return addresses, i.e. 
MAIL FROM:<[email-masked]>
RCPT TO:<[email-masked]>

I'll have to think about that some more.

>
> ... Instead of an MTA blacklist, you have an MTA whitelist.  
>

Aren't both kinds of lists logically equivalent?
Why is "not on blacklist" different from "on whitelist"?

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

---

From: Scott Nelson <[email-masked]>
Date: Wed, 30 Apr 2003 09:03:11 -0700

At 07:28 AM 4/30/03 -0400, Ken Hirsch wrote:
>From: "Kee Hinckley" <[email-masked]>
>> I'm not talking about the technical difficulty.  I'm talking about
>> the complete infeasibility of this solution from a business
>> standpoint.  It's an absolute non-starter.  Have you ever done any
>> work in the commercial email business?
>
>I'm sorry, I have no sympathy.  You're just whining, 
>"I'm not part of the problem, why should I bear any inconvenience 
> or expense?"  
> Because the current system (anarchy) is broken.
>

I have to remind myself - FAQ are asked frequently.

The IETF can not enforce a proposal.
At best, it can issue a standards document which defines what
they believe are best practices.

That means any solution perceived as being more expensive than
the current solution will not be used in practice.

Even if you somehow managed to get everyone to stop supporting
SMTP over port 25 in favor of some new, more costly solution,
people would just revive it on some other port.

-----
I often ask people if they would be willing to pay $1 a month 
to remove 95% of the spam from their mailbox and they say "yes".
If I then hand my business card, and offer to sign them up for 
$10 a year and they say "not right now".  My conclusion?
People aren't actually willing to pay very much to end spam.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 30 Apr 2003 16:25:49 -0700

No, the STARTTLS command has been implemented in most commercial
mail servers for 4 years now. The servers automatically negotiate
an upgrade to TLS inband.

		Phill

> From: Daniel Feenberg [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2003 5:51 PM
> To: [email-masked]
> On Wed, 30 Apr 2003, Claus Assmann wrote:
> 
> > Of course there is. You give up control over what happens to your
> > mail.  I can enforce TLS between hosts as long as I send mail
> > directly.  I know whether mail is stuck in the queue or whether it
> > got delivered.  Using an ISPs mailservers requires that 
> their systems
> > are actually working well and I have enough evidence to doubt that.
> 
> Wouldn't TLS traffic go via port 465 in most cases? I don't think any
> of the proposals here are intended to regulate anything 
> except port 25.
> 
> In any case, for TLS wouldn't you need explicit cooperation 
> from the the
> remote MTA, in which case the pair of you could agree to use 
> a port other
> than 25. Or is there a way to use TLS when communicating with 
> strangers?
> 
> 
> 
>