MIME-Version: 1.0
In-Reply-To: <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk>
References: <CABrd9SQYmSxOh+xBExkQ-iKGnG4dhZPBoR1U_iYLSG7kQCFE9Q@mail.gmail.com>
 <068f01cf9b53$7fc60b30$7f522190$@olddog.co.uk>
Date: Wed, 9 Jul 2014 15:04:27 +0100
Message-ID: <CABrd9ST3R7LOm3UA036vgUUMVweOY_-8nVTaut6Oszkz73_tfA@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: adrian@olddog.co.uk
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2vW6WdYn3VbU5Fll_9GMenFVdRE
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
Precedence: list

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 c=
omments to the IETF discussion list so that we can consider them as last ca=
ll 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 u=
se 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 th=
e authors to be a previously "unanswered question" and so did not need atte=
ntion in this document.
>
> That said, you are correct that the various sections do not discuss the s=
ecurity implications relating to those sections. I would be pretty loathe t=
o add security text to each section in this document: I think that would ma=
ke 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 questi=
on and add a section "How Secure is my PCE-Enabled System?" I can't think o=
f a lot to add there except for general egg-sucking guidance, but there wou=
ld be a pointer to the TCP-AO discussions currently going on in the WG. Wha=
t 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.