On Oct 03, 2014, at 09:42, Viktor Dukhovni <[email protected]> wrote:
> 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). Actually, I copied that from the version -04 and didn’t think about it, but I agree it could be confusing. The previous version didn’t include the "between client and server” text but I’d guess they meant between MUA to MTA. >> 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”. See above. >> 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. Ack - as the scope gets nailed down I’m hoping this will all get settled. spt > -- > Viktor. > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
