Keith Moore <moore@cs.utk.edu> writes:
> yes. because mail.isp.com is the name of a server which might support
> thousands of MXed domains.
That's what I figured.
> > If so, this really isn't satisfactory, because it allows
> > anyone who can tamper with the DNS to intercept mail
> > destined for any server.
>
> 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. 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
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/