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