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

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 10 July 2014 16:21 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 342751A0ABA; Thu, 10 Jul 2014 09:21:10 -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 9Asl9VdYMbT1; Thu, 10 Jul 2014 09:21:08 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC251A0AAC; Thu, 10 Jul 2014 09:21:07 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6AGL5CU013255; Thu, 10 Jul 2014 17:21:05 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6AGL3wv013237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Jul 2014 17:21:04 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Ben Laurie' <benl@google.com>
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> <CABrd9SSEk5qr9kKo552jPGiAqEVY497jjy=zRN_7hV06MOwHAw@mail.gmail.com>
In-Reply-To: <CABrd9SSEk5qr9kKo552jPGiAqEVY497jjy=zRN_7hV06MOwHAw@mail.gmail.com>
Date: Thu, 10 Jul 2014 17:21:06 +0100
Message-ID: <0cd601cf9c5a$f44424d0$dccc6e70$@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: AQH4uJ9KXH6Wajq6HAA2wc6J8Axr9gJ/ZfD4Aiae7QYBwMxQOAHFIfgBmwXk4TA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20810.000
X-TM-AS-Result: No--28.071-10.0-31-10
X-imss-scan-details: No--28.071-10.0-31-10
X-TMASE-MatchedRID: ZFzIhWOuIzunykMun0J1wpYsKSXWWrsHPj366R4tj3XadW4iYSMjUae7 nmhJA6kzFAnBoo0Pp7WnVOsT1h4vuE/duQ27+ZC8JrUxoq6hvw9+Mk6ACsw4JsbKqwGV3sczoCy y4pUARDfIszd8hbsSk15jMjt/ssG1C2s6EMq6ZtICNMj/7qB/gzZ/CJoFmAP8WltirZ/iPP5nUd ymW7X2SBqP7ooyOJMoJRg3YNJWWclQswgj0HOv3IlmrWVDo+jrIn5jqTs5ZsOynk7TnYzMulFOY nWOPByHcWhCjuUHQ73Ook4C+bdGpiU7cVZWimBbvGTc5oROod4wzcMmTIyMCg/lQ3BSNJwUiaVw q6xoriErQWrFYasPNDnxJLckdnJtzB1CJ6qmdNoj2wh8RSKcGPZpw431D6ue2Fq6de/aaIal9B9 6i8GPKNePBxJDl9ljlzl0kfrFbqFKvovRq1s4LJCYtcHXhxbaOL9BEHibhshFrqj9UzH9x6I2Wn OddDR+RVbSSCWAdDuPF2gkgF535cA1NzRSkHsOjWe5HOFKvuMW40XiUkbrG78DZBgldq9Oo8WMk QWv6iWhMIDkR/KfwI2j49Ftap9EkGUtrowrXLg=
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/mPaw_KvRthrM637G3djLli-HnQ8
Cc: 'The IESG' <iesg@ietf.org>, 'IETF Discussion List' <ietf@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
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: Thu, 10 Jul 2014 16:21:10 -0000

OK, thanks, that's clear what you'd like.

Not sure I like the approach, but I now have something to chew on. I'll get back to you.

A

> -----Original Message-----
> From: Ben Laurie [mailto:benl@google.com]
> Sent: 10 July 2014 17:02
> 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 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.
> >