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

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 09 July 2014 08:55 UTC

Return-Path: <adrian@olddog.co.uk>
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 4344D1A03B6; Wed, 9 Jul 2014 01:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 dGDEEVxKO6YL; Wed, 9 Jul 2014 01:55:15 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672C21A03B1; Wed, 9 Jul 2014 01:55:15 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s698tCad015023; Wed, 9 Jul 2014 09:55:12 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s698t926014974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Jul 2014 09:55:10 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Ben Laurie'" <benl@google.com>, "'IETF Discussion List'" <ietf@ietf.org>, <secdir@ietf.org>
References: <CABrd9SQYmSxOh+xBExkQ-iKGnG4dhZPBoR1U_iYLSG7kQCFE9Q@mail.gmail.com>
In-Reply-To: <CABrd9SQYmSxOh+xBExkQ-iKGnG4dhZPBoR1U_iYLSG7kQCFE9Q@mail.gmail.com>
Date: Wed, 9 Jul 2014 09:55:11 +0100
Message-ID: <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH4uJ9KXH6Wajq6HAA2wc6J8Axr9ptFMQaQ
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20806.005
X-TM-AS-Result: No--12.720-10.0-31-10
X-imss-scan-details: No--12.720-10.0-31-10
X-TMASE-MatchedRID: byfwvk+IcRmnykMun0J1wnBRIrj8R47F1kqyrcMalqVq4coTktrGX6+2 iUhw8uh44SA+/zgG+aNpjVjI+jMPM2hYmQszDsXl+mHRL3uzOiJyawdArtww57KeTtOdjMy6dgv 7yq6FdLNUNb4KGOm2sMg1Zg1hNKhj8a3GP7g242JIOSHptb5tx5RaYX0SmKrqSs2HWVCds5mj23 zlnPdxqJ6vrY2L+tTo48o86hCPxmWKMKSXOU/Gp9PNaYYJeRf5UAjrAJWsTe/G/Q7e2G2ERD84a DM0eBNkSPH8ly2RYDOX+cT5KI7shirmjHD28Kviw4PlNTUpnLm/yN2q8U674vdsGrGaOKdNDQ9K DzwhHMMa60S5yaTEp7/duX0pgBjTY3q3LBCbBAyeAiCmPx4NwJXxsKTUj1Z+cl9zWW7buV6y5/t FZu9S3Ku6xVHLhqfxIAcCikR3vq8h46iNBoiE5mj9AZ8h2gilpNbH4grRrU9Ex2NgktUEWud356 u8yqUH
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8PKyeWG0Us-foTN9DqRXJyhlnFo
Cc: iesg@ietf.org
Subject: Re: [secdir] Security review of draft-ietf-pce-questions-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Wed, 09 Jul 2014 08:55:17 -0000

Hi Ben,

Thanks for taking the time to review this document and for posting your comments to the IETF discussion list so that we can consider them as last call comments.

[snip]

> 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
> issues."
> 
> 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
> protocols).

I don't believe that this document is strong on "advocacy", but discusses which tools are out there and what some people do.

Previous PCE RFCs have given some attention to security concerns in the use of PCE (RFC 4655), PCE discovery (RFC 4674, RFC 5088. RFC 5089), and the PCEP (RFC 4657 and RFC 5440). As such, "PCE Security" was not deemed by the authors to be a previously "unanswered question" and so did not need attention in this document.

That said, you are correct that the various sections do not discuss the security implications relating to those sections. I would be pretty loathe to add security text to each section in this document: I think that would make the document heavy and less likely to be read by its intended consumers (it is not targeting "noobs" although they are welcome to read it).

Perhaps a solution to this *is* to treat Security as an unanswered question and add a section "How Secure is my PCE-Enabled System?" I can't think of a lot to add there except for general egg-sucking guidance, but there would be a pointer to the TCP-AO discussions currently going on in the WG. What do you think of that as a way forward?

Thanks,
Adrian