Re: [stir] Getting PASSPORT Published

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" <stir-bounces@ietf.org on behalf of adam@nostrum.com> 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
    stir@ietf.org
    https://www.ietf.org/mailman/listinfo/stir