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

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 1 Mar 2018 14:50:53 +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"
<[email-masked]> 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.
>
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 1 Mar 2018 10:53:51 -0500

Hi Jon,

> Basically, I think it could read:

Yes, thank you.  This text is very helpful.

> ecosystem. On balance I thought it was better to be up front about it,

So I agree, but the general point may be good to add as well.   The
IETF doesn't design protocols to aid surveillance, but the added text
in the privacy section is helpful to point out that this is already
done and would be done with or without this section pointing it out.

> to make sure that terms like "over-the-top" are clear.

Thank you!
Kathleen

-- 

Best regards,
Kathleen