--- 1/draft-ietf-rtcweb-alpn-01.txt 2016-01-21 19:15:20.669256030 -0800 +++ 2/draft-ietf-rtcweb-alpn-02.txt 2016-01-21 19:15:20.689256529 -0800 @@ -1,19 +1,19 @@ RTCWEB M. Thomson Internet-Draft Mozilla -Intended status: Standards Track February 28, 2015 -Expires: September 1, 2015 +Intended status: Standards Track January 21, 2016 +Expires: July 24, 2016 Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC) - draft-ietf-rtcweb-alpn-01 + draft-ietf-rtcweb-alpn-02 Abstract Application Layer Protocol Negotiation (ALPN) labels are defined for use in identifying Web Real-Time Communications (WebRTC) usages of Datagram Transport Layer Security (DTLS). Labels are provided for identifying a session that uses a combination of WebRTC compatible media and data, and for identifying a session requiring confidentiality protection. @@ -25,46 +25,46 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 1, 2015. + This Internet-Draft will expire on July 24, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 2. ALPN Labels for WebRTC . . . . . . . . . . . . . . . . . . . 2 3. Media Confidentiality . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 6 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Web Real-Time Communications (WebRTC) [I-D.ietf-rtcweb-overview] uses Datagram Transport Layer Security (DTLS) [RFC6347] to secure all peer-to-peer communications. @@ -89,64 +89,58 @@ The following identifiers are defined for use in ALPN: webrtc: The DTLS session is used to establish keys for a Secure Real-time Transport Protocol (SRTP) - known as DTLS-SRTP - as described in [RFC5764]. The DTLS record layer is used for WebRTC data channels [I-D.ietf-rtcweb-data-channel]. c-webrtc: The DTLS session is used for confidential WebRTC communications, where peers agree to maintain the confidentiality - of the communications, as described in Section 3. + of the media, as described in Section 3. However, data provided + over data channels does not receive confidentiality protection. Both identifiers describe the same basic protocol: a DTLS session that is used to provide keys for an SRTP session in combination with - WebRTC data channels. Either SRTP or data channels MAY be absent. + WebRTC data channels. Either SRTP or data channels could be absent. The data channels send Stream Control Transmission Protocol (SCTP) [RFC4960] over the DTLS record layer, which can be multiplexed with SRTP on the same UDP flow. WebRTC requires the use of Interactive Communication Establishment (ICE) [RFC5245] to establish the UDP flow, but this is not covered by the identifier. A more thorough definition of what WebRTC communications entail is included in [I-D.ietf-rtcweb-transports]. There is no functional difference between the identifiers except that an endpoint negotiating "c-webrtc" makes a promise to preserve the - confidentiality of the data it receives. + confidentiality of the media it receives. A peer that is not aware of whether it needs to request confidentiality can use either form. A peer in the client role MUST offer both identifiers if it is not aware of a need for confidentiality. A peer in the server role SHOULD select "webrtc" if it does not prefer either. 3. Media Confidentiality Private communications in WebRTC depend on separating control (i.e., signaling) capabilities and access to media [I-D.ietf-rtcweb-security-arch]. In this way, an application can establish a session that is end-to-end confidential, where the ends in question are user agents (or browsers) and not the signaling application. - A browser is required to enforce this control using isolation - controls similar to those used in cross-origin protections. These - protections ensure that media is protected from applications. - Applications are not able to read or modify the contents of a - protected flow of media. Media that is produced from a session using - the "c-webrtc" identifier MUST only be displayed to users. - Without some form of indication that is securely bound to the session, a WebRTC endpoint is unable to properly distinguish between session that requires confidentiality protection and one that does - not. + not. The ALPN identifier provides that signal. A browser is required to enforce confidentiality using isolation controls similar to those used in content cross-origin protections (see Section 5.3 [1] of [HTML5]). These protections ensure that media is protected from applications. Applications are not able to read or modify the contents of a protected flow of media. Media that is produced from a session using the "c-webrtc" identifier MUST only be displayed to users. These confidentiality protections do not apply to data that is sent @@ -209,89 +202,101 @@ might be able to sample confidential audio that is playing through speakers. This is true even if acoustic echo cancellation, which attempts to prevent this from happening, is used. Similarly, an application with access to a video camera might be able to use reflections to obtain all or part of a confidential video stream. 5. IANA Considerations The following two entries are added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by - [RFC7301]. + [RFC7301]: - The "webrtc" identifies mixed media and data communications using - SRTP and data channels: + webrtc: + + The "webrtc" label identifies mixed media and data communications + using SRTP and data channels: Protocol: WebRTC Media and Data Identification Sequence: 0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc") Specification: This document (RFCXXXX) - The "c-webrtc" identifies confidential WebRTC communications: + c-webrtc: + + The "c-webrtc" label identifies confidential WebRTC + communications: Protocol: Confidential WebRTC Media and Data Identification Sequence: 0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63 ("c-webrtc") Specification: This document (RFCXXXX) 6. References - 6.1. Normative References [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data - Channels", draft-ietf-rtcweb-data-channel-11 (work in - progress), July 2014. + Channels", draft-ietf-rtcweb-data-channel-13 (work in + progress), January 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure - Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. + Real-time Transport Protocol (SRTP)", RFC 5764, + DOI 10.17487/RFC5764, May 2010, + . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer - Security Version 1.2", RFC 6347, January 2012. + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol - Negotiation Extension", RFC 7301, July 2014. + Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, + July 2014, . 6.2. Informative References [HTML5] Berjon, R., Leithead, T., Doyle Navara, E., O'Connor, E., and S. Pfeiffer, "HTML 5", CR CR-html5-20121217, August 2010, . [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for - Browser-based Applications", draft-ietf-rtcweb-overview-11 - (work in progress), August 2014. + Browser-based Applications", draft-ietf-rtcweb-overview-15 + (work in progress), January 2016. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- - rtcweb-security-arch-10 (work in progress), July 2014. + rtcweb-security-arch-11 (work in progress), March 2015. [I-D.ietf-rtcweb-transports] Alvestrand, H., "Transports for WebRTC", draft-ietf- - rtcweb-transports-06 (work in progress), August 2014. + rtcweb-transports-10 (work in progress), October 2015. - [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC - 4960, September 2007. + [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", + RFC 4960, DOI 10.17487/RFC4960, September 2007, + . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) - Traversal for Offer/Answer Protocols", RFC 5245, April - 2010. + Traversal for Offer/Answer Protocols", RFC 5245, + DOI 10.17487/RFC5245, April 2010, + . 6.3. URIs [1] http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#origin Author's Address Martin Thomson Mozilla 331 E Evelyn Street