Subject: Re: Authentication and email

From: Eric Rescorla <[email-masked]>
Date: 31 Jan 2003 09:33:56 -0800

Paul Hoffman / IMC <[email-masked]> writes:
> At 5:15 PM +0200 1/28/03, Gonzalo Camarillo wrote:
> >And after giving them those speeches, we come back "home" to the IETF
> >and say that email security is undoable for our mailing lists for some
> >reason... it seems that MUSTs, SHOULDs and security considerations
> >sections do not apply to us ;o)
>
> This is an absurd argument. The security you are trying to achieve in
> 3GPP is completely unrelated to spam prevention.
>
> I assume that anyone who is advocating using S/MIME or PGP for
> spam-reduction has never used either protocol on a daily basis for
> mail filtering. And I say this as one of the strongest public
> proponents of those protocols. S/MIME and PGP are used for
> authenticating the content of the messages, not for authenticating
> the sender.
I'm not sure how you're drawing the distinction between providing
authentication for content and for senders. Certainly, one of the
services that S/MIME and PGP offer is data origin authentication.
Moreover, its hard to understand what the difference between
these two properties is.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 31 Jan 2003 10:29:44 -0800

At 9:33 AM -0800 1/31/03, Eric Rescorla wrote:
>authentication for content and for senders.

None of the headers are authenticated by S/MIME and PGP; only the body is.

At 9:59 AM -0800 1/31/03, James Kempf wrote:
>I would more characterize it as a category error.

Quite possibly true.

>IMHO, spam reduction has more to do with economics. As long as
>sending millions
>of unsolicited emails is cheap, the arms race between spam filters
>and spammers
>will continue.

Following this logic, the only way to use S/MIME or PGP to reduce
spam is for IETF mailing lists to reject all mail from unknown
senders, and to reject all unsigned mail from known senders. This
would certainly reduce spam; it would also reduce valid mail from new
participants and from current participants who are sending from
machines that are not set up the way their other machines are.

>However, I don't think there is a clean technical solution to this
>problem, like
>"use PGP" or "use S/MIME".

Fully agree.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "James Kempf" <[email-masked]>
Date: Mon, 3 Feb 2003 11:20:22 -0800

> machines that are not set up the way their other machines are.

I guess I don't follow you.

In fact, the IESG and IAB lists do put holds on mail from unknown senders. Three
people on IAB act as spam filterers, volunteers are selected on a half year
basis. This is a very labor intensive way of solving the problem, but it works
fairly well. Since IAB has put this system in place, there has been no spam on
the list. The lists do not require signed mail, and, as I believe you have
pointed out, requiring signed email is probably not a practical solution to the
spam problem in any event.

I don't know how other organizations do spam filtering, but I've heard of some
sophisticated, almost-AI like solutions, and others that require participants to
specifically indicate that a particular email is spam, then distribute this
information to other participants. All of these solutions suffer from problems,
such as the potential for false positives or spammers being able to quickly
change identifying information.

The point that I was trying to make is that nontechnical solutions may have a
greater probability of success solving the general problem of spam than IETF
trying to solve the problem with security mechanisms that may be difficult and
complex to deploy, put in place specifically for IETF lists. As stated, my own
opinion is that the problem is economic, so an economic solution would be the
preferable one. I'd be happy to debate this opinion, but probably not on this
list.

                jak

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 3 Feb 2003 11:59:12 -0800

>I guess I don't follow you.

Actually, you followed me just fine. We are in full agreement.

>spam problem in any event.

Exactly right. This is how the lists hosted at IMC and VPNC are run
(other than the fact that I'm the only one who audits the bounces).

>preferable one. I'd be happy to debate this opinion, but probably not on this

Sounds right to me!

--Paul Hoffman, Director

---

From: Eric Rescorla <[email-masked]>
Date: 03 Feb 2003 10:46:07 -0800

> None of the headers are authenticated by S/MIME and PGP; only the body is.
So? Examining headers to determine who senders are is a bug,
not a feature. Sender authentication is provided by cryptographic
signature of the content.

-Ekr

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 4 Feb 2003 17:08:01 -0800

At 10:46 AM -0800 2/3/03, Eric Rescorla wrote:
>not a feature.

Right. I was responding negatively to a proposal that wanted to use 
S/MIME or PGP to authenticate mail senders.

We seem to be in strong agreement here.

--Paul Hoffman, Director
--VPN Consortium

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 08 Feb 2003 20:09:34 +0200

Paul,

Paul Hoffman wrote:
> S/MIME and PGP are used for

Providing integrity without providing data origin authentication is
useless. And, of course, S/MIME provides data origin authentication.

> If that doesn't make sense to you, please go read the
> protocols: they're all on standards track and have been for many
> years. Summaries and links to the RFCs can be found at
> <http://www.imc.org/smime-pgpmime.html>.

Well, you can use S/MIME with self-signed certificates in a SSH-like
fassion to authenticate the sender of a SIP MESSAGE, for instance.

Once you can authenticate a user, the spamer needs to really subscribe
to the mailing list in order to send SPAM. Right now, using a forgued
>From field is enough. No subscription needed.

And even if you believe that authentication of users buys you nothing
regarding SPAM prevention, at least we would be *implementing* security
int he IETF mailing lists, which was Dean's original argument.

Any user agent that can send instant messages using SIP, MUST implement
S/MIME... if we believe that it is acceptable to send emails to the IETF
mailing lists without using any kind of security, why do we mandate
S/MIME for instant messages? That was the issue Dean was talking about.
3GPP was strongly opposed to that MUST S/MIME, but we insisted that it
had to be in the spec.

Gonzalo

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 8 Feb 2003 11:10:25 -0800

>From field is enough. No subscription needed.

Of course. But you are ignoring the contrapositive: no one can post
to an IETF mailing list without using S/MIME. You can't post from any
of the current Web-based mail systems. You can't post from kiosk. You
can't post from a new computer until you have copied your S/MIME keys
to the new system (and we all know how easy that is, don't we?).

Does that serve the IETF well? Is the cost worth the benefit? Are
there other ways that reach the benefit that have different costs?

>int he IETF mailing lists, which was Dean's original argument.

Why? What transpires on IETF lists that need any security? If some
people want to sign their messages, they can do that (and often do).
What you are proposing forces everyone to use security for no stated
value.

>3GPP was strongly opposed to that MUST S/MIME, but we insisted that it

Ah, now *there's* a topic worthy of IETF-wide discussion! Where was
the security needed? What are the attack scenarios? Could it have
been implemented optionally, like we have in mail?

--Paul Hoffman, Director

---

From: Derek Atkins <[email-masked]>
Date: 10 Feb 2003 16:44:46 -0500

> been implemented optionally, like we have in mail?

Yea, and look how secure our email system is....  The IESG has already
stated that optional security is bad (because optional security means
no security).  Let's not revisit that rathole.

> --Internet Mail Consortium

-derek, co-chair IMPP
-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 10 Feb 2003 14:38:10 -0800

At 4:44 PM -0500 2/10/03, Derek Atkins wrote:
>Yea, and look how secure our email system is....

Well, yes, let's look. Security is available where the two end-users 
want it, and is available where any pair of servers want it. Few 
people turn it on in either step, but those who want it use it almost 
invisibly.

>   The IESG has already

We fully disagree here. Forcing visible security where none is needed 
leads to most people not wanting to use security. If security is free 
or very low-cost, it should be required. When it is any more 
expensive either in processing time or in user hassle, it should be 
optional and easy to implement if used.

--Paul Hoffman, Director
--VPN Consortium

---

From: Derek Atkins <[email-masked]>
Date: 10 Feb 2003 21:19:53 -0500

> people turn it on in either step, but those who want it use it almost

But it generally requires both sides to agree, because it's not
ubiquitous.  If I wanted to encrypt this email, I couldn't.  Why?
Because there is no way I could -- there is no guarantee that you
could even read it (let alone have a key I could encrypt with).

So, I couldn't encrypt this email _even if I wanted to_.  That's the
problem.  I want a system where, if I want to encrypt a message, I can
be guaranteed that you can read it.  If you don't want to encrypt your
reply, that is your prerogative.

> or very low-cost, it should be required. When it is any more expensive
> either in processing time or in user hassle, it should be optional and
> easy to implement if used.

Who has the right to decide where security is needed and where it is
not?  Your idea of when it is needed is not the same as mine, and I
bet that neither of us would completely agree with some human rights
worker in Africa.  The reason I agree with the IESG is that by forcing
implementers to include security it means that users always have the
choice and don't have the problem I do with this email.

> --VPN Consortium

-derek

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 10 Feb 2003 18:41:23 -0800

At 9:19 PM -0500 2/10/03, Derek Atkins wrote:
>ubiquitous.

Which is a good indication of how few people want to use it.

>   If I wanted to encrypt this email, I couldn't.  Why?

Of course you could. If you and I agree that you should encrypt a 
message for me, it is trivial for us to agree to (particularly if we 
are using S/MIME).

>problem.

Hogwash. Find my S/MIME cert or PGP key and encrypt. If I don't make 
them available to you, you can't encrypt, but it also means I don't 
want you to.

>I want a system where, if I want to encrypt a message, I can
>be guaranteed that you can read it.

If I have an S/MIME certificate out there with an encryption key, I 
can read what you encrypt with. The same is true for a PGP key.

>not?

The user of the protocol? Naaah, that's not the IETF way.

>   Your idea of when it is needed is not the same as mine, and I
>worker in Africa.

Fully agree.

>   The reason I agree with the IESG is that by forcing

The IESG forces implementers to include security? In which universe 
does that happen? Implementers leave out the security part of lots of 
protocols that have security specified. In fact, you will find that 
most email clients have good, interoperable end-to-end security built 
in even though it is optional and rarely used. Your polemic above is 
just plain silly: anyone who wants you to send them encrypted mail 
using Internet standards can do so, usually quite easily. And 
voluntarily, too!

--Paul Hoffman, Director
--VPN Consortium

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 11 Feb 2003 17:54:35 +0100

--On mandag, februar 10, 2003 14:38:10 -0800 "Paul Hoffman / VPNC" 
<[email-masked]> wrote:

> Well, yes, let's look. Security is available where the two end-users want
> it, and is available where any pair of servers want it. Few people turn
> it on in either step, but those who want it use it almost invisibly.

realistically....

in email, security is available whenever two users want it, have mail 
systems that implement it, and there is no bit-damaging component between 
them.
at the moment I can't send secure mail between my two mail readers (because 
I have not upgraded one of them with the optional-to-install security 
components).

and about 50% of the time I see PGP-signed mail, I get the "I don't trust 
this" beep, for one reason or another.

> leads to most people not wanting to use security. If security is free or
> very low-cost, it should be required. When it is any more expensive

the IESG has "always" said that security is mandatory to *implement*.
I think we all know perfectly well that users can't be protected from 
themselves.... if they don't want it, they won't use it.

                  Harald

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 11 Feb 2003 10:22:02 -0800

At 5:54 PM +0100 2/11/03, Harald Tveit Alvestrand wrote:
>realistically....
>
>in email, security is available whenever two users want it, have 
>mail systems that implement it, and there is no bit-damaging 
>component between them.
>at the moment I can't send secure mail between my two mail readers 
>(because I have not upgraded one of them with the 
>optional-to-install security components).
>
>and about 50% of the time I see PGP-signed mail, I get the "I don't 
>trust this" beep, for one reason or another.

At the point where the IETF sets down a single interoperable standard 
for email security, this situation is likely to improve. It is even 
more likely to improve if that standard is not based on other 
standards that have known interoperability issues.

Realistically, that won't happen, but we can always hope. But we can 
learn the lessons from this debacle and try to not make the same 
mistakes with other IETF protocols.

--Paul Hoffman, Director
--VPN Consortium