Subject: [stir] Getting PASSPORT Published

From: Adam Roach <[email-masked]>
Date: Thu, 21 Feb 2019 16:23:51 -0600

[as area director]

tl;dr: I'd like to propose publishing SHAKEN as Informational instead of 
Standards Track, and tweaking the Privacy Considerations section. 
Details below.

The draft-ietf-stir-passport-shaken document still has a DISCUSS 
remaining on it from IESG evaluation:

> I would like to discuss the privacy properties of origids. As I read
> this text, it does not actually require them to be unlinkable or that
> it not be possible to determine whether two ids represent the same
> person behind the origid generator, and I believe it should do so.
> Practically implementing that may require an ID that is longer than a
> UUID.

While it's true that this behavior is defined in the ATIS document, 
publication of an IETF Proposed Standard carries with it the explicit 
indication that the IETF as a whole (including the IESG during their 
evaluation) thinks the approach being described is a Good Idea. In this 
particular case, the fact that the underlying mechanism does not 
inherently provide unlinkability for the underlying identifiers has been 
identified as problematic.

At the same time, I'll note that the primary reason for this document to 
exist is to populate two IANA registries. Both of these registries are 
"Specification Required," which doesn't require the publication of a 
Standards Track document.

An acceptable path to address this situation would be to instead publish 
draft-ietf-stir-passport-shaken as Informational, and to tighten up the 
privacy considerations slightly. I believe this could be achieved with a 
small change to the final sentence of section 10; we would replace:

>    If the operator of an element is concerned about the
>    correlation of 'origid' values, the element could be configured to
>    use a unique 'origid' value per call in such a way that the operator
>    can associate those 'origid' values to the correct element when doing
>    lookups in their backend systems.

With:

>    Absent a compelling reason not to do so, operators should configure 
> their
>    network elements to use a unique and externally unlinkable 'origid' 
> value
>    per call in such a way that the operator can associate those 'origid'
>    values to the correct element when doing lookups in their backend 
> systems.

Does this sound like a reasonable path forward?

/a

---

From: Mary Barnes <[email-masked]>
Date: Thu, 21 Feb 2019 17:12:55 -0600

I personally don't see it adds any value to make the proposed change given
that you're proposing to change the status of the draft to Informational
(which I'm fine with).  We've had this discussion many, many times with one
of those threads triggering this draft:
https://tools.ietf.org/html/draft-peterson-informational-normativity-01
 We could start it again, if you don't agree with what that draft says -
that will give us a good topic for open mic discussions at the plenary next
month ;)

I also thought IESG had published a statement on this, but I can only find
the one with regards to the references and not the terms:
https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/
.

In my view, what we have now is sufficient given the change in status.
The document highlights a potential privacy concern and suggests how it
could be addressed by service providers that deem it to be a concern.

Regards,
Mary

On Thu, Feb 21, 2019 at 4:24 PM Adam Roach <[email-masked]> wrote:

> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 21 Feb 2019 17:52:49 -0600

<as individual>

Hi Mary,

Is your argument that the original text is good enough for an informational RFC, so there’s no need to improve it? Or that the proposed new text does not improve it?

Thanks!

Ben.

> On Feb 21, 2019, at 5:12 PM, Mary Barnes <[email-masked]> wrote:
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 21 Feb 2019 17:54:38 -0600

On 2/21/19 5:12 PM, Mary Barnes wrote:
> I personally don't see it adds any value to make the proposed change 
> given that you're proposing to change the status of the draft to 
> Informational (which I'm fine with).

I'm not holding the position that the text needs to change -- that's 
coming from the DISCUSS holder. I mean, I don't think it's an 
unreasonable request, but it's not my decision to make. If you'd like to 
argue for no change, the person whose mind you need to change is EKR. 
I've copied him on this message.

>   We've had this discussion many, many times with one of those threads 
> triggering this draft: 
>  We could start it again, if you don't agree with what that draft says 
> - that will give us a good topic for open mic discussions at the 
> plenary next month ;)
>
> I also thought IESG had published a statement on this, but I can only 
> find the one with regards to the references and not the terms: 
> https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/.

Based on the two links above, I think you've confused two different 
concepts.

One is the "Normative" versus "Informative" reference sections in a 
document, which is what both of the links pertain to.

The other, which is only very loosely related, is the status of a 
published document (Proposed Standard, Best Current Practice, 
Informational, or Experimental).

The change being proposed here is to the second thing, not the first thing.

/a

---

From: Mary Barnes <[email-masked]>
Date: Thu, 21 Feb 2019 21:37:34 -0600

Responses inline below [MB]

On Thu, Feb 21, 2019 at 5:54 PM Adam Roach <[email-masked]> wrote:

> [MB] I think Chris just forwarded a response that he had previously sent.
[/MB]

> [MB] I'm not at all confused.  Jon's document talks about both concepts.
And, if you read my words,  I had thought that IESG had a statement on both
of those concepts, but it looks like it was only one (i.e., the normative
reference).  I thought maybe someone else might remember if the IESG had
done one on the other concept.  But, regardless, it's been a topic
discussed at length. [/MB]

> The change being proposed here is to the second thing, not the first thing.
[MB] Yes, I was fully aware of all of that per my comment above - maybe
next time, give me the benefit of the doubt and ask a clarifying question
before making an assumption that I'm the one that's confused. [/MB]

---

From: Mary Barnes <[email-masked]>
Date: Thu, 21 Feb 2019 21:45:08 -0600

Hi Ben,

Thanks for your question.  I am more suggesting the former than the
latter.  Although, I also don't think the proposed change adds any real
value or will have any impact on what service providers choose to do.

Regards,
Mary

On Thu, Feb 21, 2019 at 5:52 PM Ben Campbell <[email-masked]> wrote:

> <as individual>
>
> Hi Mary,
>
> Is your argument that the original text is good enough for an
> informational RFC, so there’s no need to improve it? Or that the proposed
> new text does not improve it?
>
> Thanks!
>
> Ben.
>
> given
> find

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 22 Feb 2019 19:22:28 +0000

I think the proposed privacy text is fine. 

In terms of whether this should be Info or PS, I think we're expecting that there will be a substantial amount of SHAKEN deployment out there before the end of this year. We wanted this documented here in the IETF because we wanted to make sure those PASSporT elements would be commonly understood by elements that receive them. 

Should privacy concerns prevent this from being something that gets the blessing of IETF consensus? On balance, I don't think they should. Practically speaking, these orig IDs are not the main PII worry here - the originating number, the thing STIR exists to attest, is far more revealing than an orig ID, which is in practice used something a bit more like a trunk group identifier. Carriers have the proper incentives to make sure that those orig IDs are not externally linkable. But if the worry here is that targeted or mass collection of orig ID can tell us something more interesting about the people placing communications than the calling party number, it's hard for me to see how that would be true. And even if it were, the text (especially the new version) is already telling people to keep this UUIDs opaque.

Jon Peterson
Neustar, Inc.

On 2/21/19, 2:24 PM, "stir on behalf of Adam Roach" <[email-masked] on behalf of [email-masked]> wrote:

    [as area director]

    

    

    

    /a

---

From: Adam Roach <[email-masked]>
Date: Fri, 22 Feb 2019 13:32:47 -0600

Copying EKR, as I'm not sure he reads the STIR list regularly.

/a

---

From: Chris Wendt <[email-masked]>
Date: Sat, 23 Feb 2019 11:19:47 -0500

Hi Jon,

Thanks, this aligns very similarly with the response i provided in early January on what i now am realizing was only the stir authors and working group chair lists. 

origID will only likely provide information about a particular trunk or network element a customer might be associated with, but we are already exposing orig and dest, as well as OCN association in the certificate, so origID would be the last thing on that list i would want to correlate calls with to expose privacy information.

-Chris

> On Feb 22, 2019, at 2:32 PM, Adam Roach <[email-masked]> wrote:
>