Re: [secdir] SECDIR Review of draft-ietf-pcp-description-option-02

<mohamed.boucadair@orange.com> Fri, 15 November 2013 07:40 UTC

Return-Path: <mohamed.boucadair@orange.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 5692111E80DC for <secdir@ietfa.amsl.com>; Thu, 14 Nov 2013 23:40:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.247
X-Spam-Level:
X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VHEG-q0WceS for <secdir@ietfa.amsl.com>; Thu, 14 Nov 2013 23:40:03 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB5111E80F6 for <secdir@ietf.org>; Thu, 14 Nov 2013 23:39:59 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 5A97A18C1FB; Fri, 15 Nov 2013 08:39:58 +0100 (CET)
Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 3C15A4C056; Fri, 15 Nov 2013 08:39:58 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Fri, 15 Nov 2013 08:39:58 +0100
From: mohamed.boucadair@orange.com
To: Phillip Hallam-Baker <hallam@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-pcp-description-option@tools.ietf.org" <draft-ietf-pcp-description-option@tools.ietf.org>
Date: Fri, 15 Nov 2013 08:39:54 +0100
Thread-Topic: SECDIR Review of draft-ietf-pcp-description-option-02
Thread-Index: Ac7hnZZWE/nBvyXiT1OSQ6TChDQvwQANGxuA
Message-ID: <94C682931C08B048B7A8645303FDC9F36F324262D9@PUEXCB1B.nanterre.francetelecom.fr>
References: <CAMm+LwgtbcWxLJ6t_12NqOx2tAqMJNAEFc57Pqh=imrH44Fx9A@mail.gmail.com>
In-Reply-To: <CAMm+LwgtbcWxLJ6t_12NqOx2tAqMJNAEFc57Pqh=imrH44Fx9A@mail.gmail.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36F324262D9PUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.14.54215
Subject: Re: [secdir] SECDIR Review of draft-ietf-pcp-description-option-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 15 Nov 2013 07:40:07 -0000

Dear Phillip,

Thank you for the review.

The option as defined in the document does not influence the decision-making process of the PCP Server. Furthermore, a PCP client is not allowed to retrieve a description associated with a state maintained by the server; all what it can do is to erase it, add one or update an existing one.

Given this clarification, do you still think there is an issue that should be addressed? Thanks.

Cheers,
Med


De : Phillip Hallam-Baker [mailto:hallam@gmail.com]
Envoyé : vendredi 15 novembre 2013 01:57
À : secdir@ietf.org; draft-ietf-pcp-description-option@tools.ietf.org
Objet : SECDIR Review of draft-ietf-pcp-description-option-02

  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.

The document adds a 'description' option to the PCP protocol. The description does not have defined semantics in PCP. As such the Security Considerations relies on the considerations in the PCP specification.

This seems ill advised to me. Even though the field has no semantics in PCP it is essentially the equivalent of a TXT RR in the DNS, possibly the most over-used and abused RR in the DNS protocol.

If the description option is added then people are going to start using it to define site local semantics unless there is some other mechanism for that purpose. I suggest that the draft authors either add a description of how to use the PCP mechanisms for this purpose (if applicable) or describe a mechanism to support this use and preferably providing some sort of protection against collisions.

Such a mechanism needs to consider the authenticity of the data provided and the risk that it might disclose data to another application.


--
Website: http://hallambaker.com/