idnits 2.17.1 draft-thomson-rtcweb-alpn-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 9, 2014) is 3670 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 263 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-07 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-09 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-09 == Outdated reference: A later version (-17) exists of draft-ietf-rtcweb-transports-03 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track April 9, 2014 5 Expires: October 11, 2014 7 Application Layer Protocol Negotiation for Web Real-Time Communications 8 (WebRTC) 9 draft-thomson-rtcweb-alpn-00 11 Abstract 13 Application Layer Protocol Negotiation (ALPN) labels are defined for 14 use in identifying Web Real-Time Communications (WebRTC) usages of 15 Datagram Transport Layer Security (DTLS). Labels are provided for 16 identifying a session that uses a combination of WebRTC compatible 17 media and data, and for identifying a session requiring 18 confidentiality protection. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 11, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 56 2. ALPN Labels for WebRTC . . . . . . . . . . . . . . . . . . . 2 57 3. Media Confidentiality . . . . . . . . . . . . . . . . . . . . 3 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 6.2. Informative References . . . . . . . . . . . . . . . . . 6 63 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 Web Real-Time Communications (WebRTC) [I-D.ietf-rtcweb-overview] uses 69 Datagram Transport Layer Security (DTLS) [RFC6347] to secure all 70 peer-to-peer communications. 72 Identifying WebRTC protocol usage with Application Layer Protocol 73 Negotiation (ALPN) [I-D.ietf-tls-applayerprotoneg] enables an 74 endpoint to positively identify WebRTC uses and distinguish them from 75 other DTLS uses. 77 Different WebRTC uses can be advertised and behavior can be 78 constrained to what is appropriate to a given use. In particular, 79 this allows for the identifications of sessions that require 80 confidentiality protection. 82 1.1. Conventions and Terminology 84 At times, this document falls back on shorthands for establishing 85 interoperability requirements on implementations: the capitalized 86 words "MUST", "SHOULD" and "MAY". These terms are defined in 87 [RFC2119]. 89 2. ALPN Labels for WebRTC 91 The following four labels are defined for use in ALPN: 93 webrtc The DTLS session is used to establish keys for a Secure Real- 94 time Transport Protocol (SRTP) - known as DTLS-SRTP - as described 95 in [RFC5764]. The DTLS record layer is used for WebRTC data 96 channels [I-D.ietf-rtcweb-data-channel]. 98 c-webrtc The DTLS session is used for confidential WebRTC 99 communications, where peers agree to maintain the confidentiality 100 of the communications, as described in Section 3. 102 A more thorough definition of what WebRTC communications entail is 103 included in [I-D.ietf-rtcweb-transports]. 105 3. Media Confidentiality 107 Private communications in WebRTC depend on separating control (i.e., 108 signaling) capabilities and access to media 109 [I-D.ietf-rtcweb-security-arch]. In this way, an application can 110 establish a session that is end-to-end confidential, where the ends 111 in question are user agents (or browsers) and not the signaling 112 application. 114 Without some form of indication that is securely bound to the 115 session, a WebRTC endpoint is unable to properly distinguish between 116 session that requires confidentiality protection and one that does 117 not. 119 A browser is required to enforce confidentiality using isolation 120 controls similar to those used in content cross-origin protections 121 (see Section 5.3 [1] of [HTML5]). These protections ensure that 122 media is protected from applications. Applications are not able to 123 read or modify the contents of a protected flow of media. Media that 124 is produced from a session using the "c-webrtc" identifier MUST only 125 be displayed to users. 127 A WebRTC implementation MUST only send media over a "c-webrtc" 128 session that comes from user-controlled sources. Media from sources 129 that are controlled by third parties (such as the signaling 130 application) could be used to create confusion about the content and 131 origin of data. This cannot prevent confusion when rendered as a web 132 page, for example, but browsers are required to provide ways to 133 identify media and its provenance (see Section 5.5 of 134 [I-D.ietf-rtcweb-security-arch]). 136 Confidentiality protections of this sort are not expected to be 137 possible for data that is sent using data channels. Thus, it is 138 expected that data channels will not be employed for sessions that 139 negotiate confidentiality. In the browser context, confidential data 140 depends on having both data sources and consumers that are 141 exclusively browser- or user-based. No mechanisms currently exist to 142 take advantage of data confidentiality, though some use cases suggest 143 that this could be useful, for example, confidential peer-to-peer 144 file transfer. 146 Generally speaking, ensuring confidentiality depends on 147 authenticating the communications peer. However, this mechanism 148 explicitly does not depend on authentication; a WebRTC endpoint that 149 accepts a session with this ALPN identifier MUST respect 150 confidentiality no matter what identity is attributed to a peer. 152 4. Security Considerations 154 Confidential communications depends on more than just an agreement 155 from browsers. 157 Information is not confidential if it is displayed to those other 158 than to whom it is intended. Peer authentication 159 [I-D.ietf-rtcweb-security-arch] is necessary to ensure that data is 160 only sent to the intended peer. 162 This is not a digital rights management mechanism. Even with an 163 authenticated peer, a user is not prevented from using other 164 mechanisms to record or forward media. This means that (for example) 165 screen recording devices, tape recorders, portable cameras, or a 166 cunning arrangement of mirrors could variously be used to record or 167 redistribute media once delivered. Similarly, if media is visible or 168 audible (or otherwise accessible) to others in the vicinity, there 169 are no technical measures that protect the confidentiality of that 170 media. In other cases, effects might not be temporally localized: 171 transmitted smells could linger for a period after communications 172 cease. 174 The only guarantee provided by this mechanism and the browser that 175 implements it is that the media was delivered to the user that was 176 authenticated. Individual users will still need to make a judgment 177 about how their peer intends to respect the confidentiality of any 178 information provided. 180 On a shared computing platform like a browser, other entities with 181 access to that platform (i.e., web applications), might be able to 182 access information that would compromise the confidentiality of 183 communications. Implementations MAY choose to limit concurrent 184 access to input devices during confidential communications session. 186 For instance, another application that is able to access a microphone 187 might be able to sample confidential audio that is playing through 188 speakers. This is true even if acoustic echo cancellation, which 189 attempts to prevent this from being possible, is used. Similarly, an 190 application with access to a video camera might be able to use 191 reflections to access confidential video. 193 5. IANA Considerations 195 The following two entries are added to the "Application Layer 196 Protocol Negotiation (ALPN) Protocol IDs" registry established by 197 [I-D.ietf-tls-applayerprotoneg]. 199 The "webrtc" identifies mixed media and data communications using 200 SRTP and data channels: 202 Protocol: WebRTC Media and Data 204 Identification Sequence: 0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc") 206 Specification: This document (RFCXXXX) 208 The "c-webrtc" identifies confidential WebRTC communications: 210 Protocol: Confidential WebRTC Media and Data 212 Identification Sequence: 0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63 213 ("c-webrtc") 215 Specification: This document (RFCXXXX) 217 6. References 219 6.1. Normative References 221 [I-D.ietf-rtcweb-data-channel] 222 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 223 Channels", draft-ietf-rtcweb-data-channel-07 (work in 224 progress), February 2014. 226 [I-D.ietf-tls-applayerprotoneg] 227 Friedl, S., Popov, A., Langley, A., and S. Emile, 228 "Transport Layer Security (TLS) Application Layer Protocol 229 Negotiation Extension", draft-ietf-tls-applayerprotoneg-05 230 (work in progress), March 2014. 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, March 1997. 235 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 236 Security (DTLS) Extension to Establish Keys for the Secure 237 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 239 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 240 Security Version 1.2", RFC 6347, January 2012. 242 6.2. Informative References 244 [HTML5] Berjon, R., Leithead, T., Doyle Navara, E., O'Connor, E., 245 and S. Pfeiffer, "HTML 5", CR CR-html5-20121217, August 246 2010, . 248 [I-D.ietf-rtcweb-overview] 249 Alvestrand, H., "Overview: Real Time Protocols for Brower- 250 based Applications", draft-ietf-rtcweb-overview-09 (work 251 in progress), February 2014. 253 [I-D.ietf-rtcweb-security-arch] 254 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 255 rtcweb-security-arch-09 (work in progress), February 2014. 257 [I-D.ietf-rtcweb-transports] 258 Alvestrand, H., "Transports for RTCWEB", draft-ietf- 259 rtcweb-transports-03 (work in progress), March 2014. 261 6.3. URIs 263 [1] http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#origin 265 Author's Address 267 Martin Thomson 268 Mozilla 269 331 E Evelyn Street 270 Mountain View, CA 94041 271 US 273 Email: martin.thomson@gmail.com