On Sun, Oct 5, 2014 at 7:08 PM, Sean Turner <[email protected]> wrote: > 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.
Huh? Even if you don't want authentication, you should still pay attention to integrity and confidentiality issues. Currently the draft isn't organized to separate recommendations that way: maybe it should. > > 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 -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
