[secdir] Security review of draft-ietf-pce-questions-06

Ben Laurie <benl@google.com> Fri, 04 July 2014 12:09 UTC

Return-Path: <benl@google.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0B2D31B2D63 for <secdir@ietfa.amsl.com>; Fri, 4 Jul 2014 05:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6ETaGxQYLHYB for <secdir@ietfa.amsl.com>; Fri, 4 Jul 2014 05:09:53 -0700 (PDT)
Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA84E1B286A for <secdir@ietf.org>; Fri, 4 Jul 2014 05:09:52 -0700 (PDT)
Received: by mail-qc0-f169.google.com with SMTP id c9so1433640qcz.14 for <secdir@ietf.org>; Fri, 04 Jul 2014 05:09:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EWw2HatA+uziywEzZ8BKfgOUbZmdvZd0fNMYr8dzTfg=; b=NTHZWCNcDzgJHquxitGibAPPM96uiT2kI4If5uy+yk7whW0Zf1OOSH5wFSoF4u57g0 Se/cwNzOYExe9B7vhPh9FNlg+pQkDaiwtlA1EMkFFlCzjY0rtTo0AVeuzGb87SE1toWV qziH7rTI9JQOc+Mn5ik9SlVSheSReSB9zKADZyjKZFHgF5+zz5WaxwcpjGS8oZ4wEbEf syjtPddRzlhB+N0R0ZeS9LhJYHfI6pf5Aek88N5kKQ60KMCAI4cHyj3XVOm73ZTnqImP 6Ig190KcJxyypHH1p0cq/UwSVROtaBQkESGQVYTvSOkfKHIZn7yi8kaIVtOdMyvCcKsD dM/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=EWw2HatA+uziywEzZ8BKfgOUbZmdvZd0fNMYr8dzTfg=; b=gVmtL+YTwXJikQkGGNSc0pGKeDJKG3PZ3cNeNdaS7sthfJjl+8S3iAVTD1JuUb0Shx ptd/wT9f9uORlpVwSJhzKKctwiRrQZfRI2jCs746D/h1gGJbp24IKkIegB5m0cQ25HZT Ukd01pbc4Zc2/W5Xrexu+tS1n7gK1p8kDxdNlC7U2bcxTPy7/C0UkyzgD6wMyS8ovRsn 8EvvSOMq+ClSIPGtRz8D2h9IuTMXDVlIpC5AHTiXmBgP8RPsHnIqLXUKvgGLwNOSYkvF 0KY+hAJjMxFuF3ACXH4wvEunGFCxCZO2s/0ol6Nt8ZtWk6tyg75dHiXvAgmf6i3AchsX y5GA==
X-Gm-Message-State: ALoCoQkhnpEFMuCENpuxmuktF6uHZ/QWP1Xjwub+gGKHrkVtsWwj2beQQz619aycj/hG0/8KL8J2
MIME-Version: 1.0
X-Received: by with SMTP id e9mr17484700qcs.5.1404475792168; Fri, 04 Jul 2014 05:09:52 -0700 (PDT)
Received: by with HTTP; Fri, 4 Jul 2014 05:09:52 -0700 (PDT)
Date: Fri, 4 Jul 2014 13:09:52 +0100
Message-ID: <CABrd9SQYmSxOh+xBExkQ-iKGnG4dhZPBoR1U_iYLSG7kQCFE9Q@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: IETF Discussion List <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/IQuixD5p6JosC4KkI1eflrjDMzg
Subject: [secdir] Security review of draft-ietf-pce-questions-06
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: <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, 04 Jul 2014 12:09:54 -0000

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.

Status: ready with issues.

The security considerations section makes this claim:

"This informational document does not define any new protocol elements
or mechanism.  As such, it does not introduce any new security

I agree with the premise, but not the conclusion: just because an RFC
does not introduce new security issues, that does not mean that there
are no security considerations.

Indeed, this RFC discusses many things that have quite serious
security considerations, without mentioning any of them. For example,
section 4 "How Do I Find My PCE?" (the very first question) advocates
a number of potentially completely insecure mechanisms with no mention
of their security properties (or otherwise). This is obviously
pervasive, given the stance taken in the security considerations.

The document does mention that RFC 6952 gives a security analysis for
PCEP, and perhaps this is sufficient but it seems to me that a
document intended to give useful background information to noobs
should include security directly in that information rather than defer
to another giant document (which mixes PCEP info with other