Re: [Gen-art] Gen-ART review of draft-ietf-rtcweb-alpn-03 (Was: Re: [Gen-art] Gen-ART review ofdraft-ietf-rtcweb-alpn-03)

Jari Arkko <> Thu, 05 May 2016 01:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F344F12D18F; Wed, 4 May 2016 18:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cHSEE6ylLKMo; Wed, 4 May 2016 18:32:43 -0700 (PDT)
Received: from ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id 06D2312B004; Wed, 4 May 2016 18:32:43 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 402062CC6F; Thu, 5 May 2016 04:32:42 +0300 (EEST) (envelope-from
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i246FT5TyRtj; Thu, 5 May 2016 04:32:41 +0300 (EEST)
Received: from [] ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id C1EAD2CC64; Thu, 5 May 2016 04:32:40 +0300 (EEST) (envelope-from
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-rtcweb-alpn-03 (Was: Re: [Gen-art] Gen-ART review ofdraft-ietf-rtcweb-alpn-03)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_C295A90A-8212-4C4B-8C7C-7B02334EC7B6"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
From: Jari Arkko <>
In-Reply-To: <>
Date: Wed, 4 May 2016 21:31:20 -0400
Message-Id: <>
References: <>
To: Russ Housley <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: IETF Gen-ART <>,, IETF <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 May 2016 01:32:46 -0000

Thanks for your review, Russ!

> 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
> channels."
> 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.

I agree with the above points.

Authors, have you seen these are you preparing any edits?


> Nits:
> 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
> work:
>   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.
> _______________________________________________
> Gen-art mailing list