ietf
[Top] [All Lists]

Re: IAB policy on anti-spam mechanisms?

2003-03-12 08:24:52
Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:

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

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.

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

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

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 think you mean "every domain";
Yes. Loose speaking on my part.

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

-- 
[Eric Rescorla                                   ekr(_at_)rtfm(_dot_)com]
                http://www.rtfm.com/