idnits 2.17.1 draft-saintandre-strint-workshop-xmpp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 255 -- Looks like a reference, but probably isn't: '2' on line 257 ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-14) exists of draft-ietf-dane-srv-04 == Outdated reference: A later version (-11) exists of draft-ietf-xmpp-dna-05 == Outdated reference: A later version (-06) exists of draft-ietf-xmpp-posh-00 == Outdated reference: A later version (-07) exists of draft-miller-xmpp-e2e-06 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft &yet 4 Intended status: Standards Track T. Alkemade 5 Expires: August 17, 2014 6 February 13, 2014 8 STRINT Workshop Position Paper: Strengthening the Extensible Messaging 9 and Presence Protocol (XMPP) 10 draft-saintandre-strint-workshop-xmpp-02 12 Abstract 14 This document describes existing and potential future efforts at 15 strengthening the Extensible Messaging and Presence Protocol (XMPP), 16 for discussion at the W3C/IAB workshop on Strengthening the Internet 17 Against Pervasive Monitoring (STRINT). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 17, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Per-Hop Encryption . . . . . . . . . . . . . . . . . . . . . 3 56 4. End-to-End Encryption . . . . . . . . . . . . . . . . . . . . 4 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 7.2. Informative References . . . . . . . . . . . . . . . . . 5 62 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] 68 (along with its precursor, the so-called "Jabber protocol") has been 69 used since 1999 for instant messaging(IM), presence, and other forms 70 of near-real-time communication. 72 XMPP has a distributed client-server architecture, with one hop from 73 a client to a server and one hop between any two servers, for a total 74 of at most three hops on the communication path from a given client 75 to another client. Although XMPP has supported per-hop channel 76 encryption using Transport Layer Security (TLS) [RFC5246] since 2004 77 through a STARTTLS upgrade mechanism on the standard XMPP ports (with 78 a hardcoded TLS-only port for the client-to-server hop since 1999), 79 in practice TLS has not been universally deployed for operational 80 reasons. In the last few months, operators of XMPP services have 81 been working to deploy TLS more widely, and those efforts are 82 summarized in this document. 84 Given the client-server architecture of XMPP, per-hop encryption 85 using TLS does not protect messages inside the application servers 86 that are used for routing. Therefore, various efforts have been made 87 to provide end-to-end object encryption for the payloads of XMPP 88 "stanzas". To put it mildly, these efforts have been less than 89 completely successful. This document also summarizes the state of 90 end-to-end encryption for XMPP. 92 2. Terminology 94 Various security-related terms are to be understood in the sense 95 defined in [RFC4949]. 97 3. Per-Hop Encryption 99 As mentioned, XMPP includes the ability to protect each hop in a 100 communication path using Transport Layer Security (TLS). Although 101 per-hop encryption does not protect XMPP payloads from attacks 102 against XMPP servers (since absent end-to-end encryption the payloads 103 would still be cleartext within the servers), it does protect against 104 eavesdropping on the relevant XML streams. Because eavesdropping on 105 unprotected XML streams would reveal personally identifying 106 information such as a user's contact list (which in XMPP is stored on 107 the server) and the intended recipients of a user's messages, 108 protecting all the hops in a communication path is critically 109 important for maintaining the privacy and security of XMPP-based 110 interactions. 112 Until recently, client-to-server streams were widely protected on the 113 XMPP network, but server-to-server streams were not. This state of 114 affairs has had many causes: 116 o The lack of TLS protection was not as visible to end users or 117 server administrators. 119 o Several major XMPP services did not offer or negotiate TLS over 120 server-to-server streams. 122 o Deployment of proper certificates for authenticated encryption is 123 operationally impossible in multi-tenanted environments. 125 The last item deserves some explanation. Many instant messaging 126 clients "hardcode" the connection hosts for multi-tenanted domains. 127 For example, if the XMPP service for example.com is serviced by 128 hosting.example.net (and example.net is a large enough service 129 provider), many IM clients will provide a "wizard" interface that 130 enables the end user to choose "example.net" as a service type or 131 provider when configuring an account. As a result, the client 132 software will hide the security details of the connection to 133 example.com and override identity mismatches of the kind otherwise 134 forbidden by the security considerations of the core XMPP 135 specification [RFC6120] and the "CertID" specification [RFC6125]. 136 However, because these overrides are not applied on server-to-server 137 streams, many existing implementations and deployments do not even 138 attempt TLS negotiation for server-to-server streams. 140 Although a technology like DANE/DNSSEC (see [I-D.ietf-dane-srv]) or 141 POSH/HTTPS (see [I-D.ietf-xmpp-posh] and [I-D.ietf-xmpp-dna]) would 142 provide means to overcome the operational limitations of 143 authenticated encryption, neither is yet widely deployed. Thus, in 144 practice, when server-to-server streams are being protected often the 145 technology used is unauthenticated encryption via TLS and the XMPP 146 Server Dialback extension [XEP-0220]. 148 In late 2013, a number of service operators in the XMPP community 149 committed to mandating encryption on all hops under their control, 150 and a number of software developers committed to supporting the 151 features needed to make such encryption possible. The goal is to 152 enable such encryption permanently on May 19, 2014. So far, one test 153 day has been held (on January 4, 2014) and another test day will be 154 held (on February 22, 2014) before the date of the STRINT workshop. 155 The test day revealed bugs in several XMPP software implementations 156 and prompted security improvements at a number of deployed services. 158 Also helpful has been the "IM Observatory" site at [1]. Most IM 159 clients allow end users to inspect their connection to determine 160 whether it is encrypted or not. However, users cannot easily 161 determine the status of the other hops on the path to a user on a 162 different server. Thus the IM Observatory has multiple goals: to 163 give end users a tool with which they can examine the security of the 164 entire end-to-end path, to give service operators information about 165 improvements they can make to their servers' security, and to give 166 all XMPP developers helpful statistics about the entire network. 168 4. End-to-End Encryption 170 The XMPP community has experimented with a significant number of end- 171 to-end encryption technologies, including OpenPGP [XEP-0027], S/MIME 172 [RFC3923], SIGMA [XEP-0116], end-to-end TLS 173 [I-D.meyer-xmpp-e2e-encryption], XML encryption (never publicly 174 documented), CMS with JOSE formats [I-D.miller-xmpp-e2e], and Off- 175 the-Record (OTR) Messaging [2]. Unfortunately, none of these 176 technologies has been formalized through a standards development 177 organization. However OTR is the most widely implemented. 179 5. IANA Considerations 181 This document requests no actions of the IANA. 183 6. Security Considerations 185 This entire document discusses security. 187 7. References 189 7.1. Normative References 191 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 192 4949, August 2007. 194 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 195 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 197 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 198 Protocol (XMPP): Core", RFC 6120, March 2011. 200 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 201 Verification of Domain-Based Application Service Identity 202 within Internet Public Key Infrastructure Using X.509 203 (PKIX) Certificates in the Context of Transport Layer 204 Security (TLS)", RFC 6125, March 2011. 206 7.2. Informative References 208 [I-D.ietf-dane-srv] 209 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 210 Based Authentication of Named Entities (DANE) TLSA records 211 with SRV and MX records.", draft-ietf-dane-srv-04 (work in 212 progress), February 2014. 214 [I-D.ietf-xmpp-dna] 215 Saint-Andre, P. and M. Miller, "Domain Name Associations 216 (DNA) in the Extensible Messaging and Presence Protocol 217 (XMPP)", draft-ietf-xmpp-dna-05 (work in progress), 218 February 2014. 220 [I-D.ietf-xmpp-posh] 221 Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP 222 (POSH)", draft-ietf-xmpp-posh-00 (work in progress), 223 February 2014. 225 [I-D.meyer-xmpp-e2e-encryption] 226 Meyer, D. and P. Saint-Andre, "XTLS: End-to-End Encryption 227 for the Extensible Messaging and Presence Protocol (XMPP) 228 Using Transport Layer Security (TLS)", draft-meyer-xmpp- 229 e2e-encryption-02 (work in progress), June 2009. 231 [I-D.miller-xmpp-e2e] 232 Miller, M., "End-to-End Object Encryption and Signatures 233 for the Extensible Messaging and Presence Protocol 234 (XMPP)", draft-miller-xmpp-e2e-06 (work in progress), June 235 2013. 237 [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption 238 for the Extensible Messaging and Presence Protocol 239 (XMPP)", RFC 3923, October 2004. 241 [XEP-0027] 242 Muldowney, T., "Current Jabber OpenPGP Usage", XSF XEP 243 0027, November 2006. 245 [XEP-0116] 246 Paterson, I., Saint-Andre, P., and D. Smith, "Encrypted 247 Session Negotiation", XSF XEP 0116, May 2007. 249 [XEP-0220] 250 Miller, J., Saint-Andre, P., and P. Hancke, "Server 251 Dialback", XSF XEP 0220, September 2013. 253 7.3. URIs 255 [1] https://xmpp.net/ 257 [2] https://otr.cypherpunks.ca/ 259 Authors' Addresses 261 Peter Saint-Andre 262 &yet 264 Email: ietf@stpeter.im 266 Thijs Alkemade 268 Email: me@thijsalkema.de