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 <jari.arkko@piuha.net> Thu, 05 May 2016 01:32 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F344F12D18F; Wed, 4 May 2016 18:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHSEE6ylLKMo; Wed, 4 May 2016 18:32:43 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 06D2312B004; Wed, 4 May 2016 18:32:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 402062CC6F; Thu, 5 May 2016 04:32:42 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i246FT5TyRtj; Thu, 5 May 2016 04:32:41 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id C1EAD2CC64; Thu, 5 May 2016 04:32:40 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
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 <jari.arkko@piuha.net>
In-Reply-To: <D8017772-5403-4C20-B69A-D6BB841A26E2@vigilsec.com>
Date: Wed, 4 May 2016 21:31:20 -0400
Message-Id: <B05F107A-91D2-4CE3-8FEE-F3D12E00E630@piuha.net>
References: <D8017772-5403-4C20-B69A-D6BB841A26E2@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/9x6d8Zr4nKmiKU69DUe0tZqlQUU>
Cc: IETF Gen-ART <gen-art@ietf.org>, draft-ietf-rtcweb-alpn.all@ietf.org, IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=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?

Jari

> 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
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art