[pcp] Stephen Farrell's No Objection on draft-ietf-pcp-third-party-id-option-05: (with COMMENT)

"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Wed, 27 January 2016 10:47 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: pcp@ietf.org
Delivered-To: pcp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCE51A3BA0; Wed, 27 Jan 2016 02:47:38 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160127104738.22470.43252.idtracker@ietfa.amsl.com>
Date: Wed, 27 Jan 2016 02:47:38 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/pcp/iFNLhX06Hz5dStJqjGT_-4O_fPQ>
Cc: pcp@ietf.org, draft-ietf-pcp-third-party-id-option@ietf.org, pcp-chairs@ietf.org
Subject: [pcp] Stephen Farrell's No Objection on draft-ietf-pcp-third-party-id-option-05: (with COMMENT)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jan 2016 10:47:39 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-pcp-third-party-id-option-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pcp-third-party-id-option/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


I had a discuss ballot on this, now clearing, as per below...

(1) The THIRD_PARTY stuff in PCP was always a bit concerning
from a security point of view. RFC 6887 says that you MUST NOT
implement or use that except in some specific environments. At
the time we would have liked to say that you MUST use PCP
authentication when using that but RFC 7652 wasn't done until
some time later. My DISCUSS question though is: why can't you
distinguish based on a Key ID used with PCP authentication?
Wouldn't that help with the privacy concerns (one can manage
Key IDs well if one wants) and also with the secrity concerns,
and I would guess it should solve the tunnel issues that this
is intended to address as well? (There may be good reasons why
that doesn't work of course, but I'd like to understand them.)

Jan 27:
It turns out that using PCP authentication to do this is
not a good idea - the use-cases in question have the same
PCP client and server acting for many third parties, so it'd
not be a good plan to try handle the third party id via PCP
authentication keying.

However, the document probably still should at least say
when to use PCP authentication, at present it doesn't
refer to that RFC at all.

(2) Section 7: The "must be fully trusted" phrase is not a good
one to use - iirc that was a compromise figured out to allow
PCP to proceed ahead of the PCP auth spec.  And of course, it's
really a nonsense. I think you should properly characterise the
issues or else delete the unfortunate phrase. I also think you
should not encourage the use of this for carrying location or
profile information.  What "Means" exist that could be used to
really protect this? And why do you want to "protect
unauthorized access"? that's oddly phrased at best. All in all
I think you need better text for section 7, and I'm happy to
try help find that.

Jan 27:
The authors have changed the wording. I'm still not keen
that there are so many SHOULD statements, and would
argue that it'd be better saying that this option MUST NOT
be sent outside one operator network. I hope that'll be
resolved via Alissa's discuss point and others though.

I (still) share the concerns relating to possible use of long
term identifiers here and thus support the DISCUSSes from
Alissa and Joel.