Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)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(_at_)rtfm(_dot_)com]
http://www.rtfm.com/