Re: [stir] Getting PASSPORT Published

[Chris Wendt <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Copying EKR, as I'm not sure he reads the STIR list regularly.
> 
> /a
> 
> On 2/22/19 1:22 PM, Peterson, Jon wrote:
>> 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" <[e-mail] on behalf of [e-mail]> wrote:
>> 
>>     [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
>>          _______________________________________________
>>     stir mailing list
>>     [e-mail]
>>     https://www.ietf.org/mailman/listinfo/stir
>>     
>> _______________________________________________
>> stir mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/stir
> 
>