Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC)
Mozilla
331 E Evelyn Street
Mountain View
CA
94041
US
martin.thomson@gmail.com
RAI
RTCWEB
Internet-Draft
ALPN
Protocol
Identifier
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 from web
applications.
Web Real-Time Communications (WebRTC) uses
Datagram Transport Layer Security (DTLS) to secure all
peer-to-peer communications.
Identifying WebRTC protocol usage with Application Layer Protocol
Negotiation (ALPN) enables an endpoint to positively identify WebRTC uses and
distinguish them from other DTLS uses.
Different WebRTC uses can be advertised and behavior can be constrained to what is
appropriate to a given use. In particular, this allows for the identifications of sessions
that require confidentiality protection from the application that manages the signaling for
the session.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in .
The following identifiers are defined for use in ALPN:
The DTLS session is used to establish keys for Secure Real-time Transport Protocol
(SRTP) - known as DTLS-SRTP - as described in . The DTLS record
layer is used for WebRTC data
channels.
The DTLS session is used for confidential WebRTC communications, where peers agree to
maintain the confidentiality of the media, as described in . However, data provided over data channels do not receive
the same level of 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 could be absent. The data channels send Stream Control
Transmission Protocol (SCTP) 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) 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 .
There is no functional difference between the identifiers except that an endpoint
negotiating c-webrtc makes a promise to preserve the
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 need confidentiality protection.
Private communications in WebRTC depend on separating control (i.e., signaling) capabilities
and access to media . 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. This allows an
application to manage signaling for a session, without having access to the media that is
exchanged in the session.
Without some form of indication that is securely bound to the session, a WebRTC endpoint is
unable to properly distinguish between a session that requires this confidentiality
protection and one that does not. The ALPN identifier provides that signal.
A browser is required to enforce this confidentiality protection using isolation controls
similar to those used in content cross-origin protections (see Section 5.3
of ). 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 using data channels.
Confidential data depends on having both data sources and consumers that are exclusively
browser- or user-based. No mechanisms currently exist to take advantage of data
confidentiality, though some use cases suggest that this could be useful, for example,
confidential peer-to-peer file transfer. Alternative labels might be provided in future to
support these use cases.
Generally speaking, ensuring confidentiality depends on authenticating the communications
peer. This mechanism explicitly does not define a specific authentication method; a WebRTC
endpoint that accepts a session with this ALPN identifier MUST respect confidentiality no
matter what identity is attributed to a peer.
RTP middleboxes and entities that forward media or data cannot promise to maintain
confidentiality. Any entity that forwards content, or records content for later access by
entities other than the authenticated peer, MUST NOT offer or accept a session with the
c-webrtc identifier.
Confidential communications depends on more than just an agreement from browsers.
Information is not confidential if it is displayed to those other than to whom it is
intended. Peer authentication is
necessary to ensure that data is only sent to the intended peer.
This is not a digital rights management mechanism. Even with an authenticated peer, a user
is not prevented from using other mechanisms to record or forward media. This means that
(for example) screen recording devices, tape recorders, portable cameras, or a cunning
arrangement of mirrors could variously be used to record or redistribute media once
delivered. Similarly, if media is visible or audible (or otherwise accessible) to others in
the vicinity, there are no technical measures that protect the confidentiality of that
media.
The only guarantee provided by this mechanism and the browser that implements it is that the
media was delivered to the user that was authenticated. Individual users will still need to
make a judgment about how their peer intends to respect the confidentiality of any
information provided.
On a shared computing platform like a browser, other entities with access to that platform
(i.e., web applications), might be able to access information that would compromise the
confidentiality of communications. Implementations MAY choose to limit concurrent access to
input devices during confidential communications sessions.
For instance, another application that is able to access a microphone 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.
The following two entries are added to the "Application Layer Protocol Negotiation (ALPN)
Protocol IDs" registry established by :
The webrtc label identifies mixed media and data
communications using SRTP and data channels:
WebRTC Media and Data
0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc")
This document (RFCXXXX)
The c-webrtc label identifies confidential WebRTC
communications:
Confidential WebRTC Media and Data
0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63
("c-webrtc")
This document (RFCXXXX)
HTML 5