Subject: Re: IAB policy on anti-spam mechanisms?

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Feb 2003 19:37:45 -0600

Phil,

Wednesday, February 26, 2003, 9:14:01 PM, you wrote:
PK> I would like to propose that the IAB consider drafting and adopting a
PK> position statement on the highly deleterious effect that certain 
PK> anti-spam mechanisms have on legitimate, efficient uses of the Internet.

The timing of your note is interesting.  Last summer I tried to debate
the port 25 issues with Nanog folks.  I've now given up that debate
because to many of them think it is useful.  Telling that, for
example, spammers have simply started using webmail as a channel does
not seem to matter.  (Let's see them start to block port 80...)

So at the recent Nanog meeting I tried to suggest a collaborative
effort between the IETF and ops folks to formulate a BCP that
specifies a single, preferred set of choices for doing remote email
access.

Here is a copy of the note I posted on 30 January, to Nanog:

Folks,

The Ops community and the IETF Email community appear to have different
views about appropriate methods for email posting. The difference
frequently means that an effort to post a new message from a network
with a firewall, to a remote SMTP, is blocked by the outbound firewall.

Blocking outbound SMTP (port 25) is supported by the Ops community as a
spam-suppression mechanism. Ops support for this blockage appears to be
deeply and broadly held.

This note is *not* an effort to debate the Ops concern or the preference
for blocking outbound port 25. Rather, I would like to pursue a
discussion that simply resolves the disparity between the two
communities.

The goal is to obtain a coherent recommendation that is acceptable to
the Ops and the Email communities.

It would permit normal users to easily use their normal software and
achieve normal access to normal services. Whatever the current choices
are, they are inconsistently available and they frequently require
technically knowledgeable users and/or special cooperation by the user's
remote ISP.

My guess is that a brief IETF BCP document would suffice for describing
the recommended profile. For completeness, I suggest that the BCP cover
"Remote email access" for posting and retrieval, and that it recommend
the details that will permit private, authenticated access for all
standardized email services.

Some current choices:

Email standards provide for posting of email to the usual port 25 or to
port 773 for the newer "submit" service. (Submit is a clone of SMTP that
operates on a different port and is permitted to evolve independently of
SMTP, in order to tailor posting by originators, differently from
server-to-server email relaying.) There is also a de facto standard for
doing SMTP over SSL on port 465, although this collides with the IANA
assignment of that port to another service.

Standardized SMTP authentication uses the SMTP Auth command or the SASL
service within SMTP. It can also use the de fact "POP hack". All 3 of
these mechanisms are inline -- as part of the posting protocol -- so
that they work over whatever port is being used for posting.

Standardized privacy for SMTP uses SMTP over SSL or it uses SMTP with
SASL.  SASL can be used on any SMTP or Submit port.  SSL can only be
used on port 25 if the SMTP service is not available to other SMTP
servers for relaying (or, really, for last-hop SMTP delivery).

Some choices are easier for users.  Some are easier for service
providers.  Some are supported more broadly in current software.

We need to narrow down the recommended choices, preferably to one per
service.

Thoughts?

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: [email-masked]
Date: Sat, 01 Mar 2003 23:31:37 -0800

>That being said, whining about lack of transparency is not going to
>change the behavior of the operators. The IETF should rather do
>something useful, e.g. make sure that IPSEC is easy to deploy...

In other words, we need to develop and deploy network architectures
and technologies that deliberately make it difficult for lower level
(in more ways than one) entities to arbitrarily discriminate in the
traffic they carry.

ISPs and backbone operators have so far evaded being regulated as
common carriers, so we may have to resort to technological means to
achieve the same end.  This may become the single most important role
for encryption in the Internet.

But IPSEC isn't enough. Because it isn't yet widely used, they may get
away with simply blocking protocol 50. (Some ISPs already arbitrarily
prohibit VPNs unless you upgrade to an expensive commercial service,
regardless of how little traffic you actually generate.)

We may need to mimic a form of encrypted traffic that is already
widely used by individuals, say TCP connections to port 443 (HTTP over
SSL). Since everyone knows that the only legitimate use of the
Internet is to buy junk with credit cards, no ISP would dare block
that!

As much fun as it would be to put large, monopolistic ISPs like
Comcast or AOL in their place, in all seriousness I would still much
prefer to reason with them. I would try to convince them that
arbitrarily blocking traffic against their end users' wishes is in no
one's long-term interests, including theirs. "We do it because we can"
won't work forever.

If it becomes necessary to riddle the Internet with unfilterable
encrypted tunnels, it will become impossible for the ISPs to filter
even the traffic that everyone *does* want filtered, such as the UDP
packets that propagated the recent Slammer worm. This is why I still
think it would be useful to issue a position statement along the lines
I suggested: that individual end users, not ISPs, must always control
what is and isn't filtered on their behalf.

This could be coupled with IETF-standardized protocols for the end
users to directly control these filtering mechanisms, something that
we already know would be invaluable during a denial-of-service attack.

Phil

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Mar 2003 08:30:54 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Francis" == Francis Dupont <[email-masked]> writes:
    mcr> The "nicest" solution that I can see is for the ISPs to
    mcr> transparently proxy port 25 to their MTA. They should offer
    mcr> STARTTLS.
   
    Francis> => I don't understand the word "transparently" here (:-). If one
    Francis> of my ISPs does such things, I'll sue it immediately: we have
    Francis> laws in France to protect the secrecy of private mails. I'll be
    Francis> surprised if there is none in USA.

  "transparently" means that it splices itself into the TCP connection,
creating a new connection to your intended destination. 
  cf: transparent HTTP proxies, and alg firewalls such as Janus (Borderware),
Blackhole (SecureIt), and Eagle (Axent).

  I'm not in the USA, so I can't speak about it.
  I think that legislating that email is private doesn't help make it so.
Deploying PGP or S/MIME widely, and educating people about its use would be
more effective.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Franck Martin <[email-masked]>
Date: Thu, 13 Mar 2003 11:10:02 +1200

The whole problem is that nobody sells certificates that can sign other
certificates.

If verisign gives a "signing" certificate to the ISP then the system works.

If we know who is the sender, then we can actively take action against him
outside the net in the real world. Like Caller ID phoning, they are pretty
reliable.

The most important thing, is that a certificate must be tied up to something
that gives me the contact (legal) of the person in real life (like a bank
account number, or credit card, or something else).

Franck Martin

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Thursday, 13 March 2003 10:18 
> To: Matt Crawford
> Cc: Keith Moore; [email-masked]
> Subject: Re: IAB policy on anti-spam mechanisms?
> 
> 
> "Matt Crawford" <[email-masked]> writes:
> 
> > > > Not clear.  SMTP can relay a single copy of a message 
> to multiple
> > > > recipients at multiple domains.  Your suggestion would force a
> > > > separate TLS session, or a separate SMTP session, for 
> every distinct
> > > > recipient domain.
> > > 
> > > Yes, that's true, but that's inherent in the "one certificate"
> > > model.
> > 
> > Not quite inherent -- if you verify against a SubjectAltName dNSName
> > you can decide the certificate is valid for many domains.
> Yes, this is true in theory, but I want to know how you're going
> to get VeriSign to issue you a certificate with subjectAltNames
> corresponding to a bunch of unrelated domains. And remember
> that ever time the ISP gets a new customer they have to get a new
> cert from VeriSign with yet another subjectAltName? This seems
> impractical.