Thanks Chris, these changes address my review comments.

Francesca

On 04/11/2018, 19:55, "Chris Wendt" <[email protected]> wrote:

    Thank Francesca for the review.  Comments inline.
    
    > On Nov 2, 2018, at 12:14 PM, Francesca Palombini 
<[email protected]> 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.
    
    
    

_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to