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

Phillip Hallam-Baker <hallam@gmail.com> Sat, 16 November 2013 03:18 UTC

Return-Path: <hallam@gmail.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 583C911E816B for <secdir@ietfa.amsl.com>; Fri, 15 Nov 2013 19:18:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level:
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 IeW5AoiEETuI for <secdir@ietfa.amsl.com>; Fri, 15 Nov 2013 19:18:29 -0800 (PST)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E4C1E11E813A for <secdir@ietf.org>; Fri, 15 Nov 2013 19:18:28 -0800 (PST)
Received: by mail-lb0-f173.google.com with SMTP id w7so3330363lbi.18 for <secdir@ietf.org>; Fri, 15 Nov 2013 19:18:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=doYmOSPsjpv6mWidXWXW1RGeHf+0gqNOQ24R4eIXZ3s=; b=TOft7KDFWs0IBiY/VVfXwFSilH92xBtZYxRqx/iozuYR8SjPuNDFzDiB55mB+5ez56 vbHwINb+reWW4Aoh1HQXDgf9YRtjKTppoJIZGxBLa6jgZbfF+Pv7bjmpFnvyhhXgIE9e rgcxvqwIuv2kOaX4MX+PuSEIDdWbVZ5ZGZ3nknqbQBEE1kdlzhlqU2ZoHf0BYHGPaOx+ L9ZW47/khhx3c+F4IbRB/Ev36LmbV6bC/JS2ieZQeaXwzRDj4yZb3vTgpODj6Epo4m6N 3BnSnUxraJrjUUQfG/TIA0KYq7V4dfkuimCSEaIwwarTTgEpmk0vjYXAKI3JnaMZC19k SQ9w==
MIME-Version: 1.0
X-Received: by 10.112.56.177 with SMTP id b17mr536363lbq.74.1384571907759; Fri, 15 Nov 2013 19:18:27 -0800 (PST)
Received: by 10.112.46.98 with HTTP; Fri, 15 Nov 2013 19:18:27 -0800 (PST)
In-Reply-To: <CEAADCA1.602A%repenno@cisco.com>
References: <CAMm+LwgtbcWxLJ6t_12NqOx2tAqMJNAEFc57Pqh=imrH44Fx9A@mail.gmail.com> <CEAADCA1.602A%repenno@cisco.com>
Date: Fri, 15 Nov 2013 22:18:27 -0500
Message-ID: <CAMm+LwjbtxU726pD8CqxFtKpPLDw0E_f+edbQ2NjAijUVq3z-g@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>
Content-Type: multipart/alternative; boundary="001a1133ab8aba63df04eb42c40f"
Cc: "draft-ietf-pcp-description-option@tools.ietf.org" <draft-ietf-pcp-description-option@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
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: Sat, 16 Nov 2013 03:18:30 -0000

On Thu, Nov 14, 2013 at 11:24 PM, Reinaldo Penno (repenno) <
repenno@cisco.com> wrote:

>  Hello Phillip,
>
>  Thanks for the review. Inline with [RP]
>
>   From: Phillip Hallam-Baker <hallam@gmail.com>
> Date: Thursday, November 14, 2013 4:56 PM
> To: "secdir@ietf.org" <secdir@ietf.org>, "
> draft-ietf-pcp-description-option@tools.ietf.org" <
> draft-ietf-pcp-description-option@tools.ietf.org>
> Subject: SECDIR Review of draft-ietf-pcp-description-option-02
> Resent-From: <draft-alias-bounces@tools.ietf.org>
> Resent-To: <dwing@cisco.com>, "mohamed.boucadair@orange.com" <
> mohamed.boucadair@orange.com>, Cisco Employee <repenno@cisco.com>
> Resent-Date: Thursday, November 14, 2013 4:57 PM
>
>     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.
>
>  [RP] Different from DNS a PCP client can not query the description of
> its mappings.  Can you give me an example of such site local semantics so I
> can understand better your concern?  I found this:
>
>  https://support.google.com/a/answer/2716800?hl=en
>
>  But it relies on the fact that DNS clients can query such information.
>
>    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.
>
>
I presume that the reason that information is being fed into this system is
that it is expected that there will be parties that read it out.

Those may not be PCP clients but it is surely not the empty set or what
would be the point of the feature?

If you provide a communication channel between two pieces of apparatus
which has no defined function then expect it to be used in lots of
unexpected ways.


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