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

Thomas Edwards <Thomas.Edwards@fox.com> Wed, 16 November 2016 05:26 UTC

Return-Path: <Thomas.Edwards@fox.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 16C8D129670 for <secdir@ietfa.amsl.com>; Tue, 15 Nov 2016 21:26:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxgroupinc.onmicrosoft.com
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 lcNA8Cx6jw3w for <secdir@ietfa.amsl.com>; Tue, 15 Nov 2016 21:26:27 -0800 (PST)
Received: from mx0a-00195501.pphosted.com (mx0b-00195501.pphosted.com [67.231.157.160]) (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 9A251129669 for <secdir@ietf.org>; Tue, 15 Nov 2016 21:26:27 -0800 (PST)
Received: from pps.filterd (m0082293.ppops.net [127.0.0.1]) by mx0b-00195501.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uAG5Metk030837; Tue, 15 Nov 2016 21:26:26 -0800
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0019.outbound.protection.outlook.com [216.32.180.19]) by mx0b-00195501.pphosted.com with ESMTP id 26rfv90994-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 15 Nov 2016 21:26:26 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=FoxGroupInc.onmicrosoft.com; s=selector1-fox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SZllpV2ScqyblfR/vUaw+w6QuOY8EAkrS1i4fD8WOkE=; b=BhBHnxZ9569Oyb14I2MkcWAFyY4rLJMUm1r30OPZwGaOl2J3hgyUVrTlT0UiaqAtQ/1fT93drqI/uiYIdfEfWzKxgaX+aoPd+aM3llknJ4gb8qfpzVj8120/iFt8pvFLxPsIpV1W/bohI8Jmv+PVR6+x9BPT8aFD1tiYWkhMQ4g=
Received: from CY4PR05MB3109.namprd05.prod.outlook.com (10.172.157.7) by CY4PR05MB3112.namprd05.prod.outlook.com (10.172.160.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Wed, 16 Nov 2016 05:26:25 +0000
Received: from CY4PR05MB3109.namprd05.prod.outlook.com ([10.172.157.7]) by CY4PR05MB3109.namprd05.prod.outlook.com ([10.172.157.7]) with mapi id 15.01.0734.001; Wed, 16 Nov 2016 05:26:25 +0000
From: Thomas Edwards <Thomas.Edwards@fox.com>
To: Shawn M Emery <shawn.emery@oracle.com>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: Review of draft-ietf-payload-rtp-ancillary-06
Thread-Index: AQHSOZdWFP/ySUox50iUhVd97kVo0qDamr4A
Date: Wed, 16 Nov 2016 05:26:25 +0000
Message-ID: <547619FA-F754-4ACD-B2FB-4593838B487A@fox.com>
References: <3413ce55-8a13-9698-5985-7fecc8c8f038@oracle.com> <92774159-d56b-cc7f-b5cd-b8e17d038475@oracle.com>
In-Reply-To: <92774159-d56b-cc7f-b5cd-b8e17d038475@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1b.0.161010
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [76.171.122.204]
x-microsoft-exchange-diagnostics: 1; CY4PR05MB3112; 7:LRedyvwhQJI5FGaKJltgPNT7W1gsLw7sc1lWJ8MaaoLtjTuac05ITAn2HyrWqbLEBGTBF+KUQAVNSDmUUNLS745vmi0ITF1q3ZVlQW4M4/sFsD+WFwT3hQ1KlOadM5XPoZYjwTbXo0K6SuIcYQrIiXphhuozlVqrf5MDBYjmYqkP9aQAiD6LdXHk9NMzMVtvPDi1HlQP9zT7XFfLUkxnBVjO8cuGiPcBqTNUNpV5KXWs+SvRBhPiQNy72nGIPRshbt8B4q7qE9HzEGGhyXTfP0KCyQ8jWz56w//imagKk9gKhrx5zRtku5bDwS+elsN8/mch8w5bdPmvpfKa4+MtCRvEYRl+M22nZCQqVmHXWzk=
x-ms-office365-filtering-correlation-id: 3901b6c3-fb56-41fd-bd7a-08d40de11c00
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR05MB3112;
x-microsoft-antispam-prvs: <CY4PR05MB3112454253A531FDBE83164A94BE0@CY4PR05MB3112.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705)(177823376758907)(146099531331640);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6061324)(6072148); SRVR:CY4PR05MB3112; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3112;
x-forefront-prvs: 01283822F8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(43784003)(189002)(199003)(377454003)(3660700001)(77096005)(6512003)(2900100001)(189998001)(3280700002)(122556002)(2950100002)(99286002)(36756003)(4326007)(2501003)(66066001)(83716003)(82746002)(83506001)(2906002)(8676002)(68736007)(87936001)(230783001)(86362001)(229853002)(7846002)(33656002)(7736002)(105586002)(81166006)(6116002)(102836003)(92566002)(106356001)(8936002)(3846002)(305945005)(106116001)(97736004)(5001770100001)(50986999)(101416001)(5660300001)(54356999)(76176999)(4001350100001)(6506003)(81156014)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3112; H:CY4PR05MB3109.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: fox.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <E98CF6B0CE80A446942F06E4EC5085E4@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: fox.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2016 05:26:25.3194 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3112
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-15_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611160093
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/hb4CvBb0kH1Uj8c3V-PnJ7dYdk0>
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: Wed, 16 Nov 2016 05:26:29 -0000

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."

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

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

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

-Thomas

-- 
Thomas Edwards 
VP Engineering & Development
FOX Networks Engineering and Operations
thomas.edwards@fox.com
Phone: +1.310.369.6696
10201 West Pico Blvd.
Los Angeles, CA 90035

 

On 11/8/16, 12:10 AM, "Shawn M Emery" <shawn.emery@oracle.com> wrote:

    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.
    
    This draft specifies a Real-time Transport Protocol (RTP) payload format
    for ancillary data; including time code, Closed Captioning, and Active
    Format Description (AFD).
    
    The security considerations section does exist and refers to the base
    protocol specification of RTP and any profile utilized for consideration.
    The section continues that RTP does not require a single media solution,
    referencing RFC 7202, and references RFC 7201 for various mechanisms to
    secure RTP.  I agree with this assertion.  The 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.
    
    General comments:
    
    None.
    
    Editorial comments:
    
    Abstract: Does RTP and SMPTE need to be expanded first?
    Abstract: Is SMPTE ST 291-1 a normative reference?
    s/an SDI/a SDI/
    
    Shawn.
    --