Skip to main content

Last Call Review of draft-ietf-rtcweb-alpn-03

Request Review of draft-ietf-rtcweb-alpn
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-04-21
Requested 2016-04-12
Authors Martin Thomson
I-D last updated 2016-04-18
Completed reviews Genart Last Call review of -03 by Russ Housley (diff)
Secdir Telechat review of -03 by Benjamin Kaduk (diff)
Opsdir Last Call review of -03 by Carlos Pignataro (diff)
Assignment Reviewer Russ Housley
State Completed
Request Last Call review on draft-ietf-rtcweb-alpn by General Area Review Team (Gen-ART) Assigned
Reviewed revision 03 (document currently at 04)
Result Almost ready
Completed 2016-04-18
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

Document: draft-ietf-rtcweb-alpn-03
Reviewer: Russ Housley
Review Date: 2016-04-18
IETF LC End Date: 2016-04-21
IESG Telechat date: unknown

Summary:  Almost Ready

Major Concerns:  None

Minor Concerns:

In several places, the document says: "These confidentiality protections
do not apply to data that is sent using data channels."  It took me a
moment to figure out what was being said.  I think it would really help
the reader to say at the beginning something like: "The confidentiality
protections ensure that media is protected from other applications, but
the confidentiality protections do not extend to traffic on the data

Section 3 includes this paragraph:

   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.

I understand why authentication and confidentiality are often used
together.  However, it is very unclear to me why there ought to be a
linkage between c-webrtc and authentication since this service really
is only a promise to not share media with other applications.

A similar discussion in the security considerations talks about
assurance that the "media was delivered to the user that was
authenticated."  Again, if there is no authentication, I do not see
how the assurance associated with this mechanism changes.


After reading the whole document, I went back and read the Abstract
again.  I do not think it captures the real intent of the document.
I have tried to provide an alternative, but it probably needs further

   This document specifies two Application Layer Protocol Negotiation
   (ALPN) labels for use with Datagram Transport Layer Security (DTLS)
   and Web Real-Time Communications (WebRTC).  With the first label, a
   DTLS session is used to establish keys for Secure Real-time Transport
   Protocol (SRTP), known as DTLS-SRTP.  The second label also uses
   DTLS-SRTP, but the peers also agree to maintain the confidentiality
   of the media by not sharing it with other applications.