IETF Logo Mail Archive

Re: [secdir] Review of draft-ietf-payload-rtp-ancillary-06

Shawn M Emery <shawn.emery@oracle.com> Tue, 22 November 2016 07:39 UTC

Return-Path: <shawn.emery@oracle.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB7B129635 for <secdir@ietfa.amsl.com>; Mon, 21 Nov 2016 23:39:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] 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 DMJEIjL8cq_C for <secdir@ietfa.amsl.com>; Mon, 21 Nov 2016 23:39:34 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97FB7129462 for <secdir@ietf.org>; Mon, 21 Nov 2016 23:39:34 -0800 (PST)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uAM7dU3J026256 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Nov 2016 07:39:31 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id uAM7dTqE014369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Nov 2016 07:39:30 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uAM7dStE031064; Tue, 22 Nov 2016 07:39:28 GMT
Received: from [10.154.108.111] (/10.154.108.111) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Nov 2016 23:39:28 -0800
To: Thomas Edwards <Thomas.Edwards@fox.com>, "secdir@ietf.org" <secdir@ietf.org>
References: <3413ce55-8a13-9698-5985-7fecc8c8f038@oracle.com> <92774159-d56b-cc7f-b5cd-b8e17d038475@oracle.com> <547619FA-F754-4ACD-B2FB-4593838B487A@fox.com>
From: Shawn M Emery <shawn.emery@oracle.com>
Message-ID: <4e0bb21a-50fe-f527-ff70-76daaa747083@oracle.com>
Date: Tue, 22 Nov 2016 00:41:52 -0700
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <547619FA-F754-4ACD-B2FB-4593838B487A@fox.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/TrRNNHt_4RarnlTiRfZpjlUZ4xI>
Cc: "draft-ietf-payload-rtp-ancillary.all@tools.ietf.org" <draft-ietf-payload-rtp-ancillary.all@tools.ietf.org>
Subject: Re: [secdir] Review of draft-ietf-payload-rtp-ancillary-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 22 Nov 2016 07:39:35 -0000

Hi Thomas,

Sorry for the late reply, was out of the office last week. Comments 
in-line...

On 11/15/16 10:26 PM, Thomas Edwards wrote:
> Shawn,
>
> Thanks again for the Security Directorate review of of draft-ietf-payload-rtp-ancillary-06!
>
> Please see below for a list of your comments, my responses, and my suggested draft changes.
>
> Comment: “The [security considerations] section goes on to discuss the specific payload data and how to mitigate against attack by first sanity checking said data.  I'm OK with this assertion, except for the integrity check using Checksum_Word.  The nine bit checksum based on summing the nine least significant bits of four out of dozens of possible data fields doesn't seem to provide sufficient coverage for this check.”
> Response: Indeed, the nine bit checksum word does not provide sufficient coverage for a check against attack.
> Draft change: To "Also the Checksum_Word should be checked against the ANC data packet to ensure that its data has not been damaged in transit" add ", "but the Checksum_Word is unlikely to provide a payload integrity check in case of a directed attack."

I think that this addition more clearly states the limitations of 
Checksum_Word.

> Comment: Abstract: Does RTP and SMPTE need to be expanded first?
> Response: Agreed.
> Draft change: Expand RTP and SMPTE in Abstract

Thanks.

> Comment: Is SMPTE ST 291-1 a normative reference?
> Response: I believe yes, due to specific definitions of ST 291-1 data fields specified in the payload, and DID/SDID info in the Media Type parameter.
> Draft change: No change

Other standards track RFCs have referenced SMPTE standards as 
informative.  If you want this to be a normative reference then you will 
need to call this out in the IETF LC.  This allows the community to 
determine if the standard being referenced meets the criteria of a 
stable and vetted point of reference.  Please see RFC 4897.

> Comment: s/an SDI/a SDI/
> Response: SDI is an initialism.  The Chicago Manual of Style states "When an abbreviation follows an indefinite article, the choice of a or an is determined by the way the abbreviation would be read aloud."
> Draft change: No change

OK.

Regards,

Shawn.
--

v2.23.0 | Report a Bug | By Email