On Thu, Oct 02, 2014 at 05:20:56PM -0400, Sean Turner wrote:
> The deployment recommendations address the operators of application
> layer services that are most commonly used on the Internet, including
> but not limited to:
>
> o Operators of email servers who wish to protect the application-
> layer protocols with TLS (e.g., IMAP, POP3, or SMTP between client
> and server).
When you say "between client and server" do you mean "MUA to MTA"?
Because "MTA to MTA" SMTP is also between "client and server", and
so the latter phrase is potentially confusing if meant more narrowly.
The reason for the question is that TLS authentication is generally
not applicable with MTA to MTA SMTP (DANE adoption is likely around
~1000 domains at present).
> o Operators of instant-messaging services who wish to protect their
> application-layer protocols with TLS (e.g. XMPP or IRC between
> client and server).
XMPP is also generally opportunistic TLS (modulo some few DANE
early adopters), unless again "client to server" means "user-agent
to server".
> The recommendations address the utilization of all of the security services
> provided by TLS, which include the following three services:
>
> o Confidentiality: all (payload) communication is encrypted with the
> goal that no party be able to decrypt it except the
> intended peer.
>
> o Data integrity: any changes made to the communication are
> detectable by the peer.
>
> o (optionally) Authentication: the peer is the intended entity to which
> communication is desired. TLS support authentication of one or
> both peers (i.e., server authentication or server and client
> authentication).
>
> This document does not address the rare deployment scenarios where
> one of these three properties is not desired. In fact, it is so rare that
> deployers
> need to verify carefully consider why they need to deviate from the
> recommendations provided in this document. An example of an audience
> not needing confidentiality is the following: a monitored network where the
> authorities in charge of that traffic domain require full access to
> unencrypted
> (plaintext) traffic, and where users collaborate and send their traffic in
> the
> clear.
However optional authentication is far from rare. Opportunistic
TLS is quite common outside of HTTP.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
