[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.
- [pcp] Stephen Farrell's No Objection on draft-iet… Stephen Farrell