Re: [Gen-art] Genart last call review of draft-ietf-stir-passport-shaken-04

[Chris Wendt <[e-mail]>]

Thank Francesca for the review.  Comments inline.

> On Nov 2, 2018, at 12:14 PM, Francesca Palombini <[e-mail]> wrote:
> 
> Reviewer: Francesca Palombini
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-stir-passport-shaken-04
> Reviewer: Francesca Palombini
> Review Date: 2018-11-02
> IETF LC End Date: 2018-11-02
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This draft is on the right track but has open issues, described in the
> review.
> 
> Major issues:
> 
> * This draft defines the new claim "origid" for the Personal Attestation Token
> used in the SHAKEN framework, but does not give any privacy considerations
> about it and its use. [RFC6973] suggests that the privacy considerations of
> IETF protocols be documented. As required by [RFC7258], work on IETF protocols
> needs to consider the effects of pervasive monitoring and mitigate them when
> possible. I don't know SHAKEN well enough to comment on privacy issues on that,
> but this draft, as part of the IETF work, should have privacy considerations,
> particularly considering the "origid" claim.


Here is my proposed privacy consideration section, looking for any comments if this addresses things properly given the nature of SIP privacy in general.

Privacy Considerations 

As detailed in {{RFC3261}} Section 26 as well as {{RFC3323}}, SIP as a protocol inherently carries identifying information of both the initiator or 'caller' as well as the terminating party or 'callee'. 'origid', as defined in SHAKEN {{ATIS-1000074}} and described in this document is intended to be an opaque and unique identifier that is used by an originating telephone service provider to trace and identify where within their network (e.g. from a gateway or a particular service within their network) the call was initiated, so that either bad actors that may be either trying to illegitamately spoof identities or making fraudulent calls can be identified and likely stopped or held responsibiliy for the fraudulent activities.  While the opaqueness of the 'origid' identifier is intended to keep any direct or implied information regarding the origination of a set of calls that may have the same 'origid' to a minimum, it should be recognized that potential patterns whether intended or not may be able to be discovered.

> 
> Minor issues:
> 
> * Section 4: the term "verified association" is not defined in this document,
> nor in [RFC8225], nor in the SHAKEN spec referenced. Is there a way to clarify
> what is meant by it? It could be a reference.

I’ve included a new terminology text as follows to address above comment and comment below:

   In addition, the following terms are used in this document:

   o  Verified association: is typically defined as an authenticated
      relationship with a device that initiated a call, for example, a
      subscriber account with a specific SIM card or set of SIP
      credentials.

   o  PASSporT: Defined in [RFC8225] is a JSON Web Token defined
      specifically for securing the identity of an initiator of personal
      communication.  This document defines a specific extension to
      PASSporT.

> 
> Nits/editorial comments:
> 
> * Terminology: I would have appreciated a short sentence mentioning [RFC8225]
> in the Terminology section.

see above

> 
> * Section 9: [RFC8224] appears without link.

fixed

> 
> * Acknowledgements: "The authors would like
>   acknowledge the work of the ATIS/SIP Forum IP-NNI Task Force to
>   develop the concepts behind this document." -> The authors would like to
>   acknowledge …
> 
fixed

> I do not repeat nits and editorials reported by Adam Roach in his review of
> this version of the document (11-19-2018,
> https://mailarchive.ietf.org/arch/msg/stir/HxVSCLPGfSgwFuvqLkWSVNI0PtQ )
> 

I have addressed these issues and plan to submit with list consensus on above text.