[secdir] Secdir review of draft-ietf-cdni-control-triggers-11

Vincent Roca <vincent.roca@inria.fr> Mon, 04 January 2016 16:27 UTC

Return-Path: <vincent.roca@inria.fr>
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 001D01A8A08; Mon, 4 Jan 2016 08:27:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.859
X-Spam-Level:
X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 8Q_ifgYBCrqu; Mon, 4 Jan 2016 08:27:35 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8593F1A89AE; Mon, 4 Jan 2016 08:27:34 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.20,521,1444687200"; d="asc'?scan'208,217";a="195528516"
Received: from geve.inrialpes.fr ([194.199.24.116]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jan 2016 17:27:32 +0100
From: Vincent Roca <vincent.roca@inria.fr>
X-Pgp-Agent: GPGMail 2.5.2
Content-Type: multipart/signed; boundary="Apple-Mail=_779C5F10-1796-48F0-BBF2-428B089AB52F"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Mon, 4 Jan 2016 17:27:31 +0100
Message-Id: <AF9FDB2A-3DA1-45C0-A624-F177A72F1DAC@inria.fr>
To: IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-cdni-control-triggers@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/Pm9RuoZ8zR1EAqkSLk1JneJL3bQ>
Subject: [secdir] Secdir review of draft-ietf-cdni-control-triggers-11
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: <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: Mon, 04 Jan 2016 16:27:41 -0000

Hello,

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.


Summary: not totally ready


There are several topics I’d like to discuss:

1- Concerning the use of TLS to carry CI/T traffic, I see it is mandatory to implement, but still optional to use (1st sentence of Section 8.1). Is it still reasonable in current Internet? At a minimum I would expect a « MUST support » / « SHOULD use ».


2- Section 8.1, please check the paragraph « Note that in a « diamond » configuration […] ». This paragraph is rather confusing to me. Confusion comes from:
  - the lack of description of the « diamond configuration ». I understand there is one dCDN on top and multiple uCDN directly connected below, am I right?
  - the notion of « content acquired from a uCDN ». If I understand correctly, it means « content that has been acquired after a uCDN request to do so ». I initially thought there were some mistakes in the use of uCDN / dCDN…


3- With this « diamond configuration », since several uCDN can act upon the same content, what happens if they behave in a non coordinated manner (i.e., in the general case)? For instance let’s imagine one of them asks the dCDN to delete the content or cancel the initial command. What happens if another uCDN then asks the dCDN to invalidate this content, providing the URL of the Trigger Status Resource which (if I understand correctly) is no longer valid? This « diamond configuration » can be a little bit tricky and no clear guideline is provided in the document.


4- Concerning privacy aspects, I would be much more cautious than the authors. For instance, I wouldn't claim "there are no privacy concerns for End Users" because the CI/T protocol does not carry information about individual End Users (section 8.3). The dCDN knows that there are users interested (or at the opposite no user interested) by a certain content in the region served by a uCDN. Therefore, the protocol only provides k-anonymity, where k is the number of End Users in the region. Depending on the content sensitivity and k value, this k-anonymity may still raise privacy issues, even if the individual End User activity logs are not available to the dCDN (I assume TLS is used to prevent eavesdropping…).


Typo:

** Section 8.3: « ... prevents parties other party..."


Cheers,

  Vincent