Cryptography Reference
In-Depth Information
Additionally, the sender of the email doesn't generally establish a direct con-
nection with the hosting provider of the recipient, but rather to his own hosting
provider, who is responsible for correctly routing the email based on the email
address domain. At a bare minimum, then, an email message probably passes
through at least three distinct TCP connections, each unrelated to the other, and
this can essentially occur at random times. The connection between the email's
sender and his own hosting provider is governed by the SMTP protocol, and the
connection between the receiver and his hosting provider is often governed by
the POP protocol, although there are other protocols that can be used.
The SSL/TLS Design and Email
The whole point of the SSL/TLS design is to protect against the dangers of
message exposure when messages are subjected to multiple hops. However,
SSL can't do that unless it has end-to-end control over a socket that starts and
ends the logical transaction. The sender must authenticate that the receiver is
the actual receiver and not an impostor before transmitting any sensitive infor-
mation. This is impossible in the context of email because the receiver — the
holder of the email address — is probably not online when the email is sent
and cannot provide credentials in the form of a certifi cate. This means that the
client must implicitly trust the SMTP server not to expose any sensitive details
about the email message in question, as well as negotiate a secure connection
with the receiver's hosting provider.
Does this mean that TLS is useless in the context of email? Not exactly, but
it doesn't provide the sort of end-to-end confi dentiality and integrity that you
probably want from a secure email relay service. However, TLS is very useful
for an SMTP server because it strongly authenticates the sender and ensures
that the sender is who it says it is, and it authorizes sending email through the
SMTP service itself. Of course, it's also useful for the client to establish that
the SMTP server is not an impostor either, and to guard against eavesdrop-
pers on the local network.
To this end, RFC 3207 describes the STARTTLS extension for SMTP for send-
ers of email and RFC 2595 describes the same extension for POP for the receiver
of the email. Still, it would be nice to protect the message itself. This is less of
a concern in the context of NNTP, where messages are always public, than in
email, where messages are almost always private.
There have been a number of attempts to design email security systems
that address end-to-end privacy; PEM and PGP both enjoyed some measure
of success at various times as de facto standards. S/MIME, described by
RFC 5751, however, is the offi cial IETF email security mechanism. S/MIME
is not actually an application of TLS because TLS was designed under the
assumption that both parties are online and capable of responding to each
Search WWH ::




Custom Search