Re: [secdir] sector review of draft-ietf-rtcweb-rtp-usage-23
Chris Inacio <inacio@cert.org> Wed, 10 June 2015 20:31 UTC
Return-Path: <inacio@cert.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610C71AC3F7; Wed, 10 Jun 2015 13:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 tKUTK0gjLpW1; Wed, 10 Jun 2015 13:31:29 -0700 (PDT)
Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5F31A8AF3; Wed, 10 Jun 2015 13:31:29 -0700 (PDT)
Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t5AKVPPD019698; Wed, 10 Jun 2015 16:31:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1433968285; bh=mzppUFy1xpGixGdkun8nL7U+O23+P0JsH+cuwZpHJB8=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-ID:Content-Transfer-Encoding:MIME-Version: Sender:Reply-To; b=cD9Yu9MKDGXM3hrybFdqbkYHCVhzOhr5tCUxlgIBiX9z/nNGOSg9QI5Pg8BkMPJ+f VGheqWQ0UxGIkov+7U2Xdj2FRlMPEzoW6sYzZUuijRJGy83q4+1hl/OJTmlb8mTT4H s/YdUK7NaLdhX2qsd4njkCbBf/jyLI2oosv5pwho=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t5AKVTCe005093; Wed, 10 Jun 2015 16:31:29 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0210.002; Wed, 10 Jun 2015 16:31:22 -0400
From: Chris Inacio <inacio@cert.org>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: sector review of draft-ietf-rtcweb-rtp-usage-23
Thread-Index: AQHQosbhcvT38Apty0Os5Xa8WMhXhJ2mJ7aAgABOk4A=
Date: Wed, 10 Jun 2015 20:31:22 +0000
Message-ID: <C75D474E-DF87-4504-9CA0-03A5E28375BF@cert.org>
References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> <55785CA7.4090005@ericsson.com>
In-Reply-To: <55785CA7.4090005@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.96.46]
Content-Type: text/plain; charset="utf-8"
Content-ID: <E0F2A1CD93EAAC49B2353DB76629D066@sei.cmu.edu>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/40MJVJwdUikGe7Sk2qGtU9UKNRQ>
Cc: "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" <draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] sector review of draft-ietf-rtcweb-rtp-usage-23
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2015 20:31:32 -0000
> On Jun 10, 2015, at 8:49 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote: > > Hi, > > (Adding RTCWEB WG list as this discusses changes to the draft) > > Thanks for the very detailed review. We will include all relevant changes in an update that will be submitted after the IESG call tomorrow. > > WG, this is your chance to scream if there are bad changes here. > > > Chris Inacio skrev den 2015-06-09 17:13: >> >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> >> BLUF: This draft is ready to go with some NITS. >> >> >> This draft is an overarching set of guidelines of the use and >> application of RTP and RTCP as it applies to WebRTC and the related >> W3C API. The W3C API is not described in this document, but >> references to functionality requirements for the API are made. >> >> This draft is extremely well written. At the same time, however, it >> reads like an encyclopedia of references and requirements across 35 >> different normative other referenced drafts. Correspondingly, I did >> NOT read through all of the referenced drafts, nor did I believe that >> it was necessary in this case to do so. >> >> The security considerations section was comprehensive and security >> impacts were taken into account throughout this draft. I have two >> small NIT’s about the security section that I would like improved, >> and I feel these are rather small: > > First, in the paragraph in the >> security section that starts “RTCP packets convey a Canonical Name…” >> the authors state that the CNAME generation algorithm in described in >> section 4.9 – it isn’t, section 4.9 references RFC7022 for the >> generation algorithm. > > Yes, but it actually specifies which particular generation algorithm to use. RFC7022 does contain more than one. > > I propose that we change this text to say: > > Section 4.9 of this memo mandates generation of short-term persistent RTCP CNAMES, as specified in RFC7022, resulting in untraceable CNAME values that alleviate this risk. > looks good. > Second, the last paragraph on page 39, >> starting with “Providing source authentication in multi-party…” ends >> the page with a large security warning. Please include a reference >> in that paragraph in the security considerations and possibly to the >> appropriate draft/RFC which discusses that issue in some more depth. > > > If I understand this correctly, you want something like the below added to the security consideration section. I suggest to add this last in the section. > > In multi-party communication scenarios using RTP Middleboxes, a lot > of trust is placed on these middleboxes to preserve the sessions > security. The middlebox needs to maintain the confidentiality, > integrity and perform source authentication. As discussed in > Section 12.1.1 the middlebox can perform checks that prevents any > endpoint participating in a conference to impersonate another. Some > additional security considerations regarding multi-party topologies > can be found in [I-D.ietf-avtcore-rtp-topologies-update]. > That would be excellent. >> >> >> general NITS: >> >> I believe there are multiple versions of “end point” used in the >> document End Point, end-point, etc. Those should be harmonized. >> > > Yes, we will use endpoint > >> >> page 4: >> >> Section 2 Rationale >> >> “This builds on the past 20 years development of RTP to mandate the >> use of extensions that have shown widespread utility” >> >> can this be reworded to “This builds on the past 20 years of RTP >> development to mandate the use of extensions that have shown >> widespread utility.” >> > > Yes. > >> >> page 6: >> >> “This specification requires the usage of a single CNAME when sending >> RTP Packet Streams…” should the “require” be “REQUIRE”? > > This is intended as an informational reference, thus I propose to change this to "mandates" thus avoiding the RFC2119 terms. > > I’m good with that. >> >> page 7: >> >> "This to ensure robust handling of future extensions…” to “This is to >> ensure…” > > Sure. > >> >> page 14: >> >> In reference to the paragraph that starts with “While the use of IP >> multicast...”. There is no MAY/SHOULD/SHALL/REQUIRE etc. in the >> paragraph, but the last sentence does seem to imply an implementation >> requirement. Was that intentional? > > Yes, it is intentional. > >> >> page 16: >> >> “This can be various reasons for this:…” to “There can be various >> reasons for this:…” > > Addressed in -24 version. > >> >> page 20: >> >> “heterogeneous network environments using a variety set of link >> technologies…” get rid of “set”. >> > Yes. > >> page 23: >> >> “…supported by the RTCP Extended Reports (XR) framework >> [RFC3611][RFC6792].” RFC3611 seems to be a full fledged reference >> while RFC6792 seems to just be text of “[RFC6792]”. >> > > They are both relevant references when understanding what RTCP XR are and what metrics one should consider. > > I propose to add a "see" so that the results become "... framework, see [RFC3611][RFC6792]. > I think I was misunderstood, likely my fault. In the PDF, the RFC3611 seemed to be a true reference in the document; but RFC6792 did NOT seem to be a reference. Maybe an issue in the actual XML, not the resulting PDF/TXT. It may be nothing. > >> page 25: >> >> First paragraph of section 11 defines a number of WebRTC API terms, >> PLEASE move those (far) forward in the document. “The >> MediaStreamTracks within a MediaStream need to be possible to play >> out synchronized.” rewrite to “The MediaStreamTracks within a >> MediaStream may need to be synchronized during play back.” or >> something similar. > > I have added also MediaStreamTrack to the Terminology section (3). And populated both MediaStream and MediaStreamTrack with text from this paragraph. I have however not removed any text from this paragraph in Section 11. > > sounds good. >> >> page 26: >> >> “force an end-point to to disrupt” only one “to”. > > Ok > >> >> “This is motivating the discussion in Section 4.9”, (yes, now I’m >> really getting picky,) but the discussion was already motivated. :) > > Changed this to: > > This is motivating the use of a single CNAME in Section 4.9. > :) >> >> page 27: >> >> “Optimizations of this method is clearly possible and …” “is” -> >> “are” > > ok > >> >> “receiving multiple MediaStreamTracks, where each of different >> MediaStreamTracks (and …” to “ … where each of *the* different >> MediaStreamTracks … “ > > Fixed > >> >> “This later is relevant to handle some cases of legacy interop.” to >> “The later is relevant … legacy interoperability.” >> > > Ok > > >> page 28: >> >> “. . . Endpoints can configure and use RTP sessions is outlined.” >> change “is” to “are” > > >> >> “ . . . it is common to use one RTP session for each type of media >> sources (e.g. . . .” change “sources” to “source” >> >> page 31: >> >> “To maintain a coherent mapping between the relation between RTP >> sessions and RTCPeerConnection objects it is …” rewrite to maybe >> >> “To maintain a coherent mapping between the relationship of RTP >> sessions and RTCPeerConnection objects it is ….” > > I propose: > > To maintain a coherent mapping of the relationship between RTP sessions and RTCPeerConnection objects it is recommend that this is implemented as several individual RTP sessions. > looks good. >> >> page 32: >> >> “This scenario also results in that an end-point’s feedback or >> requests goes to the mixer…” change “goes” to “go”. > > ok > >> >> “necessarily be explicitly visible any RTP and RTCP traffic …” to >> “necessarily be explicitly visible to any RTP and RTCP traffic”. > > Yes > >> >> page 38: >> >> “combing” to “combining” >> > > ok > >> >> >> -- Chris Inacio inacio@cert.org >> >> >> > > Cheers > > Magnus Westerlund > great. It is a very well written draft. > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > -- Chris Inacio inacio@cert.org
- [secdir] sector review of draft-ietf-rtcweb-rtp-u… Chris Inacio
- Re: [secdir] sector review of draft-ietf-rtcweb-r… Magnus Westerlund
- Re: [secdir] [rtcweb] sector review of draft-ietf… Colin Perkins
- Re: [secdir] [rtcweb] sector review of draft-ietf… Chris Inacio
- Re: [secdir] sector review of draft-ietf-rtcweb-r… Chris Inacio
- Re: [secdir] [rtcweb] sector review of draft-ietf… DRAGE, Keith (Keith)
- Re: [secdir] sector review of draft-ietf-rtcweb-r… Magnus Westerlund
- Re: [secdir] [rtcweb] sector review of draft-ietf… Magnus Westerlund
- Re: [secdir] [rtcweb] sector review of draft-ietf… Adam Roach