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