Re: [Modern] Kathleen Moriarty's Discuss on draft-ietf-modern-problem-framework-03: (with DISCUSS and COMMENT)

"Peterson, Jon" <jon.peterson@team.neustar> Thu, 01 March 2018 14:50 UTC

Return-Path: <prvs=059847ed44=jon.peterson@team.neustar>
X-Original-To: modern@ietfa.amsl.com
Delivered-To: modern@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC2B129C51; Thu, 1 Mar 2018 06:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=team.neustar
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 2RtLZ1jlksK9; Thu, 1 Mar 2018 06:50:58 -0800 (PST)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82C3129502; Thu, 1 Mar 2018 06:50:57 -0800 (PST)
Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w21Ei398032273; Thu, 1 Mar 2018 09:50:54 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=selector1; bh=LJNpnZh03RZC+JR9uhXpqTTlRlzaxUnGWE1btsBCJPg=; b=KrdurY9rOk3dkHFlBvnTet9OIGOs6pkOq89ZSvzi8SwTcmYfQCieoeOXE6z3gO1KHElf EtAi3Um/9I7uDPq4XBhu7QAlt3wc3Hr3TC5Zlt9eMCGsyDUlTOfzkI1ecPrC+NJyEI1/ 2Ht1XasjtR35fv2X43xi5rd8sGZc+Uvk4Ge6CLuAoJsMScE2vuWyM25HaUDHIFcwnk5Z jPBZUTTd/1FDOPwM4L0Qu+BCzrSI7JovaI0sxpaM/A7g+5XEZiq4yR0wZgGjDprBuD+P qlnz3mbDfH5kHnB7pITdb7hy0hIdW8rBvRnzKjaTEV0n8sa2jtn0MiqsHzDttO2Qabe6 Uw==
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 2gdqft9yqw-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 01 Mar 2018 09:50:54 -0500
Received: from STNTEXMB11.cis.neustar.com ([169.254.1.236]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 1 Mar 2018 09:50:54 -0500
From: "Peterson, Jon" <jon.peterson@team.neustar>
To: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-modern-problem-framework@ietf.org" <draft-ietf-modern-problem-framework@ietf.org>, "modern-chairs@ietf.org" <modern-chairs@ietf.org>, "srdonovan@usdonovans.com" <srdonovan@usdonovans.com>, "modern@ietf.org" <modern@ietf.org>, Yoav Nir <ynir.ietf@gmail.com>
Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-modern-problem-framework-03: (with DISCUSS and COMMENT)
Thread-Index: AQHTsWyyOrrLEbVdzECESvoi48YWjg==
Date: Thu, 01 Mar 2018 14:50:53 +0000
Message-ID: <D6BD4357.1F686E%jon.peterson@neustar.biz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.3.160329
x-originating-ip: [10.96.12.153]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <944C3885D538614186507F66D06F4199@neustar.biz>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-01_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803010186
Archived-At: <https://mailarchive.ietf.org/arch/msg/modern/bgcsJhjaqIo9GOcahx4clk_kcBI>
Subject: Re: [Modern] Kathleen Moriarty's Discuss on draft-ietf-modern-problem-framework-03: (with DISCUSS and COMMENT)
X-BeenThere: modern@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" <modern.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/modern>, <mailto:modern-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/modern/>
List-Post: <mailto:modern@ietf.org>
List-Help: <mailto:modern-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/modern>, <mailto:modern-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2018 14:50:59 -0000

Hi Kathleen (and Yoav),

We can certainly add a privacy considerations section to the document.
Basically, I think it could read:

--

This framework defines two categories of information about telephone
numbers: service data and administrative data. Service data describes how
identifiers map to particular services and devices that provide real-time
communication services to users. As such, service data could potential
leak resource locations and even lower-layer network address associated
with these services, and in rare cases with end user devices.
Administrative data more broadly characterizes who the administrative
entities are behind identifiers, which will often identify service
provides, but in some layers of the architecture could include personally
identifying information, even WHOIS-style information, about the users
behind identifiers. This could conceivably encompass the sorts of data
that carriers and similar service providers today keep about their
customers for billing purposes: real names and addresses, and similar
personally identifying information. The exact nature of that information
is not defined by this framework, and it is anticipated that the protocols
that will perform this function will be extensible for different use
cases, so at this point, it is difficult to characterize exactly how much
PII might end up being housed by these services.

As such, if an attacker were to compromise the registrar services in this
architecture which maintain administrative data, and in some cases even
service data, this could leak personally identifying information about end
users. These interfaces, and the systems the host them, are a potentially
attractive target for hackers and need to be hardened accordingly.
Protocols that are selected to fulfill these functions must provide the
security features described in [Sec Cons].

Finally, this framework recognizes that in many jurisdictions, certain
government agencies have a legal right to access service and
administrative data maintained by carriers. This access is typically aimed
at identifying the users behind communications identifiers in order to
enforce regulatory policy. Those legal entities already have this power to
access the existing data held by carriers in many jurisdictions, though
potentially the administrative data associated with this framework could
be richer information.

--

Would roughly that work? If so, will patch it in before the cut-off.

Also, regarding 4.3.4, we really are trying not to sweep under the rug
that government access is a use case for this framework. Just including
this under the general idea that you need to be authorized to access
information at these services would downplay the reality on the ground
about Gov Entities and their relationship to the whole numbering
ecosystem. On balance I thought it was better to be up front about it,

And Yoav, we will also expand some of the early language in the document
to make sure that terms like "over-the-top" are clear.

Thanks!

Jon Peterson
Neustar, Inc.

On 2/21/18, 6:51 PM, "Kathleen Moriarty"
<Kathleen.Moriarty.ietf@gmail.com> wrote:

>Kathleen Moriarty has entered the following ballot position for
>draft-ietf-modern-problem-framework-03: Discuss
>
>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-modern-problem-framework/
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>I agree with the SecDir reviewer that a Privacy Considerations section is
>needed.  What user data is potentially exposed?  4.3.4 talks about
>government
>access, who else has access?  What concerns are there about the data that
>is
>shared?  What if one of the involved systems is compromised and data is
>stolen?
>
>It's a well written draft, this appears to be a gap and I didn't see a
>response
>to the SecDir review.  Thanks in advance.
>
>https://mailarchive.ietf.org/arch/msg/secdir/1WiFmubNoAKo3qAhNu4be35g10w
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>I'm a little surprised to see section 4.3.4 instead of just a statement
>on how
>authorized access to the data is provided.
>
>