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, 04 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
- Gen-ART review ofdraft-ietf-rtcweb-alpn-03 Russ Housley
- Re: [Gen-art] Gen-ART review of draft-ietf-rtcweb… Jari Arkko
- Re: Gen-ART review ofdraft-ietf-rtcweb-alpn-03 Martin Thomson