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

From: [email-masked]
Date: Fri, 28 Feb 2003 16:40:39 -0800

>The "nicest" solution that I can see is for the ISPs to transparently
>proxy port 25 to their MTA. They should offer STARTTLS.

Assuming you're not pulling my leg, I couldn't disagree more
strongly. This is even worse than blocking port 25 outright.

I actually encountered an ISP that does this. I can't remember their
name, but they provide many of the DSL Ethernet hookups in hotel
rooms. I discovered only after I had sent a few messages that they
were hijacking (the only correct word) my outbound connections to port
25 and redirecting them to their own mailservers. They didn't support
STARTTLS, and even if they did there is no reason I should trust them.

It did teach me the importance of protecting against the
man-in-the-middle attack. This is not often done, at least not by
default, in many STARTTLS implementations.

I do agree with you about the utility of IPsec and IPv6 tunneling as
ways around this braindamage. TCP connection tunneling over SSH is
another good approach.

Phil

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 11 Mar 2003 11:59:16 -0700 (MST)

> From: [email-masked]

> Reply-to: [email-masked]

"[email-masked]"?
I've been meaning to ask about that.  If the goal is to avoid
Microsoft out-of-office noise and other hassles, wouldn't 
[email-masked] or some other obvious bit bucket be better?

> ...
> I actually encountered an ISP that does this. ...

Hasn't AOL been running SMTP redirection proxies for their IP customers
for years?

> default, in many STARTTLS implementations.

Which STARTTLS are those that cannot be told to check certificates?
By default sendmail only says "verify=FAIL" in the received header when
the authentication part fails, but I think I recall a sendmail.cf
switch that says "refuse mail without a good certificate."

Vernon Schryver    [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: 11 Mar 2003 11:21:51 -0800

> default, in many STARTTLS implementations.

Indeed. The problem is that it's pretty hard to determine
a priori what certificate the peer server ought to be offering,
due to mail relaying and MX records.

-Ekr

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

---

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 11 Mar 2003 15:31:36 -0500

From: Eric Rescorla <[email-masked]>
   Date: 11 Mar 2003 11:21:51 -0800

This is a bigger problem than just SMTP. Any protocol that uses SRV
records has this indirection and this problem.

One (poor) solution to this is codified in
draft-ietf-ldapext-locate-08:

   [when using TLS,] if the DN "cn=John
   Doe,ou=accounting,dc=example,dc=net" is converted to the DNS name
   "example.net", the server's name MUST match "example.net".

which means that if an equivalent sort of mapping is done for instant
messaging, an organization is going to have many many different
servers all with the same certificate name of "example.net". This is
especially poor when different servers are under different
administrative control.

Larry

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Mar 2003 20:14:14 -0500

> due to mail relaying and MX records.

or at least, proper behavior isn't well-defined.  IMHO, about the only 
behavior that is reasonable (assuming a single cert, which IIRC is what 
TLS assumes) is to have the peer server offer a cert for the domain 
name associated with the A record, not the one associated with the MX 
record.

this doesn't protect against bogus MX records.  but if the site doesn't 
want to be an MX for that domain then it will refuse the mail - ideally 
with an enhanced status code that indicates why the mail was refused.  
it might even be reasonable for MTAs to detect that case and handle it 
specially.

---

From: Eric Rescorla <[email-masked]>
Date: 11 Mar 2003 21:27:43 -0800

Keith Moore <[email-masked]> writes:
> behavior that is reasonable (assuming a single cert, which IIRC is
> what TLS assumes) is to have the peer server offer a cert for the
> domain name associated with the A record, not the one associated with
> the MX record.
Just to make sur I understand, do you mean that if someone is sending
mail to [email-masked], and there's an MX for rtfm.com pointing to
mail.isp.com, the cert should contain mail.isp.com in the subject
name?

If so, this really isn't satisfactory, because it allows
anyone who can tamper with the DNS to intercept mail
destined for any server.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Mar 2003 01:00:18 -0500

> mail.isp.com, the cert should contain mail.isp.com in the subject

yes.  because mail.isp.com is the name of a server which might support 
thousands of MXed domains.

> anyone who can tamper with the DNS to intercept mail

I see your point.  But I suspect it illustrates a significant 
limitation of the SSL/TLS protocol - in that SSL/TLS seems to assume 
that an IP address and port number are used by only one named service.  
It's been awhile since I looked at the TLS protocol but I don't recall 
any way for the client to say "prove to me that you are authorized to 
provide the SMTP service associated with DNS name foo.com".   or did I 
just forget that feature?

---

From: Eric Rescorla <[email-masked]>
Date: 11 Mar 2003 22:19:25 -0800

> thousands of MXed domains.
That's what I figured.

> just forget that feature?
This could be conceivably accomplished in two ways:

(1) By the application protocol (in this case SMTP) indicating
    what server the client wanted to talk to. This isn't
    possible in STARTTLS, but it could easily have been specifid
    that way. I would have designed things differently.

(2) You could use the TLS domain name extension described in
    draft-ietf-tls-extensions-06.txt, recently approved at
    Proposed by the IESG.

Unfortunately, neither of these fixes solves the real problem,
which is that it's impractical for a relaying MTA to have a
a certificate for every host it might potentially receive
mail for, but that's what's required here.

I suppose you could call this as a limitation in TLS, but it's
really a basic limitation of pretty much any channel security
scheme. If you want to do better, you really need an object
security scheme like S/MIME.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Mar 2003 07:56:06 -0500

>     what server the client wanted to talk to. 

I'm not sure how this would help.  The client could say "I want to send mail
to domain XXX" in SMTP but a rogue server is going to say "you've come to the
right place".  I suppose the client could say "prove you are the MX for domain
example.net" and the server could be expected to return a cert.  But this has
backward compatibility problems.

>     draft-ietf-tls-extensions-06.txt, recently approved at

I'll have to look at that; thanks for the ref.

> mail for, but that's what's required here.

I think you mean "every domain"; DNS names don't need to correspond to hosts
anymore (and often don't).  I'm not sure why it's inherently impractical to do
this, especially if it were possible to have a single cert that covered
multiple domains (i.e. a statement of the form "mail.isp.com is a valid MX for
*.example.net" signed by example.net). 

Keith

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 12 Mar 2003 09:09:09 -0600

> just forget that feature?

There's no reason a protocol can't be spec'd to let the client convey
the name of the resource before the TLS handshake begins.  (In some
cases, you might want to repeat that information after the stream is
protected.)  The problem is that popular existing protocols don't do
that.  Look at the contortions you have to choose among to support
HTTPS "virtual hosting".

---

From: Eric Rescorla <[email-masked]>
Date: 12 Mar 2003 07:29:08 -0800

Keith Moore <[email-masked]> writes:

> I'm not sure how this would help.  
Let's take a step back. There are two issues here:

(1) Sending anything over TLS requires that you have some
    way to determine whether the certificate you received
    is the right one. That means that it has to have
    some secure connection to the identity you actually
    are trying to talk to--in this case the e-mail address.

    In the current environment, this means that it needs
    to have a name corresponding to the domain in the e-mail
    address, because there isn't any other secure identifier.
    Of course, if we had DNSSEC then we could securely
    authenticate MX records and then relays could use their
    own certificates.

(2) Whenever a TLS server needs to potentially use more than
    one certificate (as when it's acting for multiple
    HTTPS servers) there needs to be some way to indicate
    to the server which certificate the client expects.
    This can either be done in TLS proper (see the draft
    cited below) or, if you're using an upward negotiation
    strategy such as STARTTLS, indicated in the application
    layer protocol.

    In either case, the client needs to verify that the 
    certificate matches (as in 1). We're just talking here about
    how to provide an indicator to the server as to which
    cert to use.

> The client could say "I want to send mail to domain XXX" in SMTP but
> a rogue server is going to say "you've come to the right place".  I
> suppose the client could say "prove you are the MX for domain
> example.net" and the server could be expected to return a cert.  But
> this has backward compatibility problems.
The way this would work would be that the client would tell the
server the target domain in the STARTTLS message. The server
would then use the right cert (at the moment meaning, as I said above,
the destination MTA's cert) and the client would verify it.

It's true that this is a backward compatibility problem
in that STARTTLS as currently defined doesn't actually contain
the domain name. As I indicated before, I consider this to 
be a design error. There wouldn't have been a compatibility
problem if the domain name had been included in STARTTLS from
the beginning.

> I think you mean "every domain";
Yes. Loose speaking on my part.

> DNS names don't need to correspond to hosts
Sure, if there's some straightforward way to authenticate MX
records then you can use TLS in a simple way. But Now we're
just reinventing DNSSEC using X.509. That seems like a lose.

Oh, and you'd still need the indicator mentioned above since
the client would need to to tell the server which MX-certificate
he wanted the server to proffer. That wouldn't be required 
with DNSSEC.

-Ekr

---

From: [email-masked]
Date: Wed, 12 Mar 2003 11:59:24 -0500

> *.example.net" signed by example.net). 

I believe I saw a recent reference to some hosting provider that had on the
order of half a million MX pointed at one mail server.  I'd hate to see
the size of the cert for that - 1 cert with 500K "yes, this is an agent for
me" endorsements from 500K domains.

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Mar 2003 12:35:19 -0500

On Wed, 12 Mar 2003 09:09:09 -0600
"Matt Crawford" <[email-masked]> wrote:

> > that an IP address and port number are used by only one named
> > service.  It's been awhile since I looked at the TLS protocol but I
> > don't recall any way for the client to say "prove to me that you are
> > authorized to provide the SMTP service associated with DNS name
> > foo.com".   or did I just forget that feature?
> 
> the name of the resource before the TLS handshake begins. 

no, there isn't.  but it still wouldn't give the client a way to verify
that the server is authoritative for that domain.

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Mar 2003 12:39:00 -0500

> problem if the domain name had been included in STARTTLS from

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.

Keith

-- 
"Of course the people don't want war.  But ... it is always a simple 
matter to drag the people along.  All you have to do is tell them they
are being attacked, and denounce the pacifists for lack of patriotism
and exposing the country to danger... It works the same way in any
country."

- Hermann Goering, 1947.

---

From: Eric Rescorla <[email-masked]>
Date: 12 Mar 2003 10:01:37 -0800

> separate TLS session, or a separate SMTP session, for every distinct

Yes, that's true, but that's inherent in the "one certificate"
model. Like I said earlier, if you want to have some set of
certificates vouching for MX records, then you want DNSSEC.

-Ekr

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 12 Mar 2003 13:08:28 -0600

> that the server is authoritative for that domain.

<irony>If it isn't, your trust in the CA that issued its certificate
is misplaced.</irony>

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 12 Mar 2003 13:25:20 -0600

> model.

Not quite inherent -- if you verify against a SubjectAltName dNSName
you can decide the certificate is valid for many domains.

> Like I said earlier, if you want to have some set of

But I agree with this.

---

From: Eric Rescorla <[email-masked]>
Date: 12 Mar 2003 14:17:43 -0800

> 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.

-Ekr

---

From: Doug Royer <[email-masked]>
Date: Wed, 12 Mar 2003 15:37:23 -0700

> cert from VeriSign with yet another subjectAltName? This seems

If you are talking about TLS certs (not S/MIME certs) then the ISP can
issue them to the customer directly (be a CA for connections from their
customers over TLS connections). I have read that the customer can be
given instructions on how to add the ISP cert as a trusted CA for that
usage on M$ products.

I have no idea how to get M$ products to use that cert :-)
as I do not use M$ products. I know how to do that on Unix.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: [email-masked]
Date: Wed, 12 Mar 2003 17:47:11 -0500

> given instructions on how to add the ISP cert as a trusted CA for that

Non-scaling.

The *OTHER* end of the connection won't recognize the ISP's CA, most likely.

---

From: Doug Royer <[email-masked]>
Date: Wed, 12 Mar 2003 16:36:52 -0700

> The *OTHER* end of the connection won't recognize the ISP's CA, most likely.

Maybe I misunderstood part of the previous e-mail ...

The other end would be the ISP's customer. I was not talking about
exporting the CERT to non-customers. I was talking about the ISP
issuing CERTs for their customers and rejecting all others to
port 25 for relaying. It allows roaming and is cheaper because
for "ISP-A" from/to "ISP-A customers", you do not need to buy
a cert.

So if I connect to a ISP-A port 25 and use a NON-ISP-A cert then
relaying is not allowed even when the cert is valid and from an
otherwise trusted CA. However ISP-A's customers can now have
multiple (what ever it is called in the cert) domains and they
can relay ONLY with their own ISP for ISP controlled domains.
And if you add authentication, now the ISP can control which
user(s) can relay specific domains.

And I agree with you, the big cert vendor - is not going to do that
for random customers.

--

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 12 Mar 2003 17:57:46 -0600

> corresponding to a bunch of unrelated domains. And remember ...

Ah, that. Well, we live in different PK worlds. Yours is much larger
and more congruent to plaent earth. Mine is a bunch of science labs
and universities that nearly know each other.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 12 Mar 2003 17:41:40 -0800

This thread is trying to redefine or redesign SMTP's use of TLS. It 
should probably be happening on the [email-masked] list 
instead of the main IETF mailing list. That's where the implementers 
are, and that's where the implementers of most of the foo-over-TLS 
protocols are. They too should be hearing this discussion, since much 
of it applies to many protocols, not just SMTP.

--Paul Hoffman, Director
--Internet Mail Consortium