Re: [secdir] review of draft-ietf-cdni-logging.15

"Francois Le Faucheur (flefauch)" <> Mon, 16 February 2015 15:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C84E11A1EF3; Mon, 16 Feb 2015 07:15:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -13.911
X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OPi3CNiej0Hq; Mon, 16 Feb 2015 07:15:24 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C82211A1BD1; Mon, 16 Feb 2015 07:15:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4698; q=dns/txt; s=iport; t=1424099712; x=1425309312; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=snF/w3sjoTVx+1p6ver/ftqlyTcSAijv2XzbFkelXGw=; b=FbbfxNEf9lS8EaFsdFCK3Sj6sQ2KSuUE966TMO0nuykhnyDYZNo902Tz Y8Qt9bke9Cb61X9vP6KILOLE0L3DwRj9QTBmVT17uTJ6rS3fWg2TVcfzo A5DBFcD3kC0ESb/wxLxkdxiH8nBQDtoxsrvD3fp/LNQQhdm/JO967o+yz E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.09,588,1418083200"; d="scan'208";a="396592392"
Received: from ([]) by with ESMTP; 16 Feb 2015 15:15:12 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t1GFFB8G016002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Feb 2015 15:15:12 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 09:15:11 -0600
From: "Francois Le Faucheur (flefauch)" <>
To: "Klaas Wierenga (kwiereng)" <>
Thread-Topic: review of draft-ietf-cdni-logging.15
Thread-Index: AQHQR6bsatwFQJOdLkuG1v9BlCIAFZzzy/wA
Date: Mon, 16 Feb 2015 15:15:11 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "Francois Le Faucheur (flefauch)" <>, "" <>, "" <>
Subject: Re: [secdir] review of draft-ietf-cdni-logging.15
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Feb 2015 15:15:27 -0000


Thank you Klaas. We’ll look into this shortly.


> On 13 Feb 2015, at 17:05, Klaas Wierenga (kwiereng) <> wrote:
> 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 specifies the logging format and the exchange protocol for logging information between upstream and downstream CDNs that are interconnected using the CDN interconnection framework.
> The document is well written and easy to read. I have few issues with the main text, but do have some concerns about the security and privacy considerations. I therefore consider the document “ready with issues”
> Detailed comments:
> * Introduction and Figure 1: What is not clear to me from the text is whether there is any functional difference between an uCDN and an dCDN,or that they just happen to be in a hierarchical relation to each other.  I could also find no reference to that in RFC7336. The fact that in Figure 1 dCDN-2 is not also labeled as uCDN-2 led me to believe that there is a functional difference. However from the text it appears that any two DCNs can be in an u-d relation to each other. Please clarify.
> * Paragraph 3.2  CDNI Logging File Structure
> You state that you chose a format as close as possible to the W3C ELF Format. I’d like to see a short explanation why you can not use that format, and whether it would be an option to extend that format rather than defining a new format that is slightly different but is essentially a form and could over time be significantly different.
> * paragraph 3.3 Directives
> For the Integrity-Hash you write: "hash function of all logging records and directives up to the hash-directive itself”. I have not seen that the directives are in a special order with the Integrity-hast as last one, so it appears that when the integrity-hash directive is the very first one there will be no sensible hash. Unless there is actual order in the directives (write that down) I suggest “has all logging information and directives with the exception of the Integrity-Hash directive itself”
> * Paragraph 7.1 Authentication, Confidentiality, Integrity Protection
> You leave out the 3d A, Authorization, but then you talk about mutual authentication to decide whether an entity is authorised to receive the logs, so I think you should insert it that one too.
> You state that the use of TLS for transport allows for mutual authentication, confidentiality and integrity, that in itself is not true. You need TLS + mutual authentication to get confidentiality and integrity. 
> In the text “In an environment where any such protection is required….” TLS is a "SHOULD unless…..”, Why not “MUST unless….”
> * paragraph 7.2 DoS
> I don’t understand how the use of TLS protects agains DoS, on the contrary I would say, trying to establish a TLS session is costly, so an evil entity could easily mount a DoS by trying to connect and exchange crypto material.
> Klaas
> --
> Klaas Wierenga
> Identity Architect
> Cisco Cloud Services