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

Kevin Ma J <> Mon, 27 June 2016 04:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8487812D11D; Sun, 26 Jun 2016 21:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gq3cs9_1jPHm; Sun, 26 Jun 2016 21:06:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 625B112B053; Sun, 26 Jun 2016 21:06:48 -0700 (PDT)
X-AuditID: c618062d-f79886d000002334-91-57709c2c3cf5
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 0D.8A.09012.C2C90775; Mon, 27 Jun 2016 05:23:24 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0294.000; Mon, 27 Jun 2016 00:06:46 -0400
From: Kevin Ma J <>
To: Zhang Dacheng <>, The IESG <>, "" <>
Thread-Topic: SecDir review of draft-ietf-cdni-metadata-18
Thread-Index: AQHRzf0udJRVHEg89kyuP27YcBgwfJ/8r8fQ
Date: Mon, 27 Jun 2016 04:06:46 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_A419F67F880AB2468214E154CB8A556206E355DCeusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyuXSPn67OnIJwg4OfrC3OXVjKZjHjz0Rm iw8LH7JYvL9wjsWBxeNxzxk2jyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoEr482CZ0wFp0or Zi1ZydzAuKWoi5GTQ0LARGLiyzYWCFtM4sK99WxdjFwcQgJHGSVaHu9kB0kICSxnlHjUUgli swloSTz++pcJxBYRyJPYuGorG4jNLJAosXT7FjBbWMBS4uP+K4wQNVYSu7f+YYOwjSQuXfwL FmcRUJXY8KePFcTmFfCVODt9NtAuDqBdMRI7T/KChDkFYiWWX7kI1soIdNv3U2uYIFaJS9x6 Mp8J4mYBiSV7zjND2KISLx//Y4WwlSTmvL7GDFGfL7Ht4gIWiFWCEidnPmGZwCg6C8moWUjK ZiEpmwV0EbOApsT6XfoQJYoSU7ofskPYGhKtc+ayI4svYGRfxchRWlyQk5tuZLCJERhvxyTY dHcw3p/ueYhRgINRiYdXQaIgXIg1say4MvcQowQHs5II7/pFQCHelMTKqtSi/Pii0pzU4kOM 0hwsSuK8Yo8Uw4UE0hNLUrNTUwtSi2CyTBycUg2MG5y/f+O48uDj9W8iU1oat8hvN/K7kvUn TmPelOyamWs52a54efipv9iW/cdzY1V4MX9DQaTA9avhuw9Ir1c8dqRNUDbd/PCTsDeP8/4f 2Kjz857vi5e+gimODoprtavM3Ntuvt/9TIRJJOn3J6fehUYXst53r/9066X9UV6Dxd9/xG57 btubpcRSnJFoqMVcVJwIAHduS4SzAgAA
Archived-At: <>
Cc: "" <>
Subject: Re: [secdir] SecDir review of draft-ietf-cdni-metadata-18
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jun 2016 04:06:50 -0000

Hi Dacheng,

  Thank you for the review.
  1-3. We will update the text in the next revision.
  4. I think the thought was that once authenticated, and assuming that dCDNs have access to all metadata accessible from that HostIndex, then the dCDN is authorized to retrieve the metadata; we did not try to differentiate authorization of different metadata in the tree.  Do you think it would be best to just remove that bullet, or try to clarify the text?
  5. The Source metadata tells the dCDN from where it may acquire the content that it is going to distribute.  Generally, content delivery is not necessarily authenticated.  The dCDN is likely just pulling the content from a uCDN cache, and thus would have whatever authentication policy is set there (which could be none).  The CDNI delivery authentication mechanism is being defined in draft-ietf-cdni-uri-signing.  If desired, the URI Signing object could be added.  If URI Signing is required by the content owner, the CDNs are required to maintain it; but if the content owner doesn't care (e.g., the asset is not valuable), and the uCDN doesn't care (e.g., there is no DoS concern), then the content can be sent unauthenticated, regardless of the security of the environment.


--  Kevin J. Ma

From: Zhang Dacheng []
Sent: Friday, June 24, 2016 5:46 AM
To: The IESG;
Subject: SecDir review of draft-ietf-cdni-metadata-18

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, 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?