[secdir] SecDir review of draft-ietf-cdni-metadata-18

Zhang Dacheng <zhang_dacheng@hotmail.com> Fri, 24 June 2016 09:45 UTC

Return-Path: <zhang_dacheng@hotmail.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 E482B12D529; Fri, 24 Jun 2016 02:45:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.145
X-Spam-Level:
X-Spam-Status: No, score=-4.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 Jtqm1IoQOlu5; Fri, 24 Jun 2016 02:45:50 -0700 (PDT)
Received: from BAY004-OMC4S24.hotmail.com (bay004-omc4s24.hotmail.com [65.54.190.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67FB712D14D; Fri, 24 Jun 2016 02:45:50 -0700 (PDT)
Received: from APC01-SG2-obe.outbound.protection.outlook.com ([65.54.190.199]) by BAY004-OMC4S24.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 24 Jun 2016 02:45:50 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Nw2yDYSSBgPmSjMVk5CLcIKlRoT1X+QTEcllxqQp/LI=; b=ni7AoYSP392I6JQrCZFJq0B3/QNv5VEHrJxmBsCswmbUqxtOXXU2IfnSSc0IudoXEv8Jt4xpg2wrmpfQlMTRbZcgGmK/pMLCFxbpXlYXst4Hb8TIDRzgZ9f+yIeFzW3mdE6znDBSkdH3E+80rBI1awANBUPNrSbQ4VD38Gke9OhXlRg+2TleLxxQlWxKmT8UikWDu7+w8uSCklZDw4f8CC1uathrrc8tOn4RonVGV6QZohw1VekmiVqvQeQbVKkrAtNGmO+GKS8Bs7PjJU5VQwdHgeMCbV6rzyI1GJaMAIMz6p5Mvwa6xwPowCEhTQD6wg8zYVHswsAdcDGps3O+qg==
Received: from SG2APC01FT025.eop-APC01.prod.protection.outlook.com (10.152.250.51) by SG2APC01HT145.eop-APC01.prod.protection.outlook.com (10.152.251.42) with Microsoft SMTP Server (TLS) id 15.1.511.7; Fri, 24 Jun 2016 09:45:47 +0000
Received: from HK2PR03MB0739.apcprd03.prod.outlook.com (10.152.250.53) by SG2APC01FT025.mail.protection.outlook.com (10.152.250.187) with Microsoft SMTP Server (TLS) id 15.1.511.7 via Frontend Transport; Fri, 24 Jun 2016 09:45:46 +0000
Received: from HK2PR03MB0739.apcprd03.prod.outlook.com ([10.161.187.153]) by HK2PR03MB0739.apcprd03.prod.outlook.com ([10.161.187.153]) with mapi id 15.01.0523.019; Fri, 24 Jun 2016 09:45:47 +0000
From: Zhang Dacheng <zhang_dacheng@hotmail.com>
To: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: SecDir review of draft-ietf-cdni-metadata-18
Thread-Index: AQHRzf0udJRVHEg89kyuP27YcBgwfA==
Date: Fri, 24 Jun 2016 09:45:46 +0000
Message-ID: <HK2PR03MB07391BCA12CFA57C7786EFA4882E0@HK2PR03MB0739.apcprd03.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=softfail (sender IP is 25.152.250.53) smtp.mailfrom=hotmail.com; tools.ietf.org; dkim=none (message not signed) header.d=none; tools.ietf.org; dmarc=fail action=none header.from=hotmail.com;
received-spf: SoftFail (protection.outlook.com: domain of transitioning hotmail.com discourages use of 25.152.250.53 as permitted sender)
x-ms-exchange-messagesentrepresentingtype: 1
x-eopattributedmessage: 0
x-forefront-antispam-report: CIP:25.152.250.53; IPV:NLI; CTRY:GB; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:SG2APC01HT145; H:HK2PR03MB0739.apcprd03.prod.outlook.com; FPR:; SPF:None; LANG:en;
x-ms-office365-filtering-correlation-id: fc0abe8e-e83c-4838-9f34-08d39c144f84
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(5061506196)(5061507196)(1603103041)(1601125047); SRVR:SG2APC01HT145;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:SG2APC01HT145; BCL:0; PCL:0; RULEID:; SRVR:SG2APC01HT145;
x-forefront-prvs: 0983EAD6B2
Content-Type: multipart/alternative; boundary="_000_HK2PR03MB07391BCA12CFA57C7786EFA4882E0HK2PR03MB0739apcp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2016 09:45:47.0018 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT145
X-OriginalArrivalTime: 24 Jun 2016 09:45:50.0165 (UTC) FILETIME=[30EC0850:01D1CDFD]
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/sfVjOHkmXqqInQpiQV8i3v_Nk2U>
Cc: "draft-ietf-cdni-metadata.all@tools.ietf.org" <draft-ietf-cdni-metadata.all@tools.ietf.org>
Subject: [secdir] SecDir review of draft-ietf-cdni-metadata-18
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: Fri, 24 Jun 2016 09:45:53 -0000

Hi,
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 document defines the CDNI metadata interface which enables a CDN to obtain CDNI metadata from another one.
There are some issues which should be further discussed before publishing the memo.
1. The title of Section 8.1 is Authentication, but the contents are all about unauthorized access to metadata. Maybe you could say something like ‘if an attacker can impersonate a legal CDN without being detected, it is able to…’
2. There is a big overlap between section 8.2, Confidentiality and section 8.4, Privacy. I suggest to merge these two sections.
3.In section 8.3, you mentioned, ” An implementation of the CDNI metadata interface MUST use strong encryption and mutual authentication to prevent undetectable modification of metadata (see Section 8.5).” Normally, when discussing about integrity protection, we prefer to use MAC rather than encryption.
4. In section 8.5, there is a statement about using TLS to provide authorization. I don’t think TLS can decide which meta-data can be sent/processed by a CDN.
5. In section 4.2.1.1, it is sated that by default no authentication needs to be provided when requesting content from a source. Do you assume the source will work in a secure environment?