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

Ben Laurie <benl@google.com> Thu, 10 July 2014 16:02 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C1B1A0601 for <secdir@ietfa.amsl.com>; Thu, 10 Jul 2014 09:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level:
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=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 pc1qvNuOU0dg for <secdir@ietfa.amsl.com>; Thu, 10 Jul 2014 09:02:12 -0700 (PDT)
Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93CFA1A0653 for <secdir@ietf.org>; Thu, 10 Jul 2014 09:02:12 -0700 (PDT)
Received: by mail-qc0-f180.google.com with SMTP id r5so8018109qcx.39 for <secdir@ietf.org>; Thu, 10 Jul 2014 09:02:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y3pXtWv0/nIdgO6DBLWFk+5rs6ueYyqUz3jNEAwoASk=; b=oZhNCwNTwYE+q0fzySUtQIZ2ptjySaYnkVHZey3s2m3BdAH67P8j5lCEg4104Ac3sh l6AgQLwhgyXh7JhliK2vGqN7JJDa8rFezCOMPOhhVhF3LvjPfPyd/vCAPBk/m5d4KdUU YoEKnA+m44hpIDqHqFIwuFeMFWL34T/wDLA0dvzPl+SefUYrhhSMOvk3+jwol7IubIP7 X04HHtrQfpH35rGh9nLD6IWMwKMQXE3SFWjRjbtvMMXkt7oDQq9YI/gjWnVAcQ7rUtdH rhAedYHFZN0KuZOCVdtGU6Kg1Lv/vsOzsziW9nyPdqx/ZH4IUhYbWrIb62B7CVRpQC9N ywjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=y3pXtWv0/nIdgO6DBLWFk+5rs6ueYyqUz3jNEAwoASk=; b=gP6suaaBSaPNAV7/pztYbuxkhfoEXyejinBC5+dq1gE4e8JFLwRXrbztDOy9HU9Cm2 2YkuMymeJaBWdhmSsIvL6SfABNmgHJ3kvE+bsnxhR4SNHU6VnsjRv/zknY+ZfCpRR6Re IB9KMdeMZw+KhsHT6BbavLJ41jhp7SkuTsudo/FFmJsaXEqpWM3rAgnaDvOeT4NNDb13 WWoYaopzKYalqIOEda8P5zNGN/BAWglEFvYExvEonKuo+NFzCmHLOgfpbvc4e8f2l/eN Fhu7Dpn8jks/FTmYJUJQBTn8nm3pawnYqqjEQHNTJzwVZDbK2TeMs5oRqKSWEiJ5sOhx RD8w==
X-Gm-Message-State: ALoCoQnWG39KlwcQS9KmN3Uwv7Zp4LuNz3prQd3aBe2W2Pd2L3UyBDJ3JQyIgr8xkxBDBZd4AZ6c
MIME-Version: 1.0
X-Received: by 10.140.82.113 with SMTP id g104mr79541653qgd.55.1405008131679; Thu, 10 Jul 2014 09:02:11 -0700 (PDT)
Received: by 10.229.162.15 with HTTP; Thu, 10 Jul 2014 09:02:11 -0700 (PDT)
In-Reply-To: <0cc101cf9c57$c8706290$595127b0$@olddog.co.uk>
References: <CABrd9SQYmSxOh+xBExkQ-iKGnG4dhZPBoR1U_iYLSG7kQCFE9Q@mail.gmail.com> <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk> <CABrd9ST3R7LOm3UA036vgUUMVweOY_-8nVTaut6Oszkz73_tfA@mail.gmail.com> <0cc101cf9c57$c8706290$595127b0$@olddog.co.uk>
Date: Thu, 10 Jul 2014 17:02:11 +0100
Message-ID: <CABrd9SSEk5qr9kKo552jPGiAqEVY497jjy=zRN_7hV06MOwHAw@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: adrian@olddog.co.uk
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/MVaopqKxSW_w05rObzH6U2axYGI
Cc: The IESG <iesg@ietf.org>, IETF Discussion List <ietf@ietf.org>, "secdir@ietf.org" <secdir@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
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: Thu, 10 Jul 2014 16:02:16 -0000

On 10 July 2014 16:58, Adrian Farrel <adrian@olddog.co.uk> wrote:
> Hi Ben,
>
> So you don't like my proposed solution?
>
> I am not quite sure what you do consider a resolution to your concern. I can see three options:
>
> 1. Add security-related text to each section of this document.
> 2. Beef up the Security Considerations section with a subsection related to each section of the document.
> 3. Add a new section "How Secure is my PCE-Enabled System?" as I suggested.
>
> Do you have a preference among these, or is there another option you like better?

I prefer 1, that way the security advice is likely to be read by
whoever reads that section - that is, by the people who are likely to
benefit from it.

>
> Thanks,
> Adrian
>
>
>> -----Original Message-----
>> From: Ben Laurie [mailto:benl@google.com]
>> Sent: 09 July 2014 15:04
>> To: adrian@olddog.co.uk
>> Cc: IETF Discussion List; secdir@ietf.org; The IESG
>> Subject: Re: Security review of draft-ietf-pce-questions-06
>>
>> On 9 July 2014 09:55, Adrian Farrel <adrian@olddog.co.uk> wrote:
>> > 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).
>>
>> Your position appears to be that they will then go on to read much
>> heavier documents in order to discover the security properties of the
>> solutions you suggest, which seems a little unlikely, particularly if
>> there's no mention of the necessity to do so.
>>
>> Or perhaps you think security is not important?
>>
>> > 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?
>>
>> I have no idea what discussions are going on, but once more, if you
>> are concerned about "heaviness" of documentation, pointing at ongoing
>> discussions does not strike me as a route to lightness.
>