Re: [stir] I-D Action: draft-ietf-stir-passport-shaken-02.txt

["Peterson, Jon" <[e-mail]>]

Chris and I did discuss this at some length, and we're on the same page.

Once we have a bit more deployment experience with all of this, I imagine we'll have a better view of the network requirements for message/header sizes and the possible ways we might tweak STIR down the road to make it more efficient. But we are now, I agree it makes sense to ship SHAKEN full-form only.

Jon Peterson
Neustar, Inc.

On 9/14/18, 5:31 AM, "stir on behalf of Chris Wendt" <[e-mail] on behalf of [e-mail]> wrote:

    Thanks Russ, I agree with your edits and will include in a forthcoming update.
    
    I’d also like to update the group on the status of compact form for SHAKEN.
    
    After a little more consideration, while it would be nice to have an approach that can save some bits on the wire, one of the original agreed mandates of SHAKEN was to exclusively use full form of passport.  The reason for this was concern of middle boxes that might change DATE header, for whatever reason right or wrong although mostly the latter, but we could not guarantee this wouldn’t happen.  We felt this was important to make sure we are doing our best to avoid failing the verification of the calling identity inadvertently and potentially causing a blocked call or perception of a spam call or whatever the treatment of failed verification might be.
    
    Therefore, I plan, rather than define compact form, to include text in the new update that states that compact form is not defined for SHAKEN passport extension.
    I have discussed this with Jon directly as well.
    
    Please let me know if you have any comments regarding this, otherwise i will provide an updated document shortly.
    
    Thanks
    
    -Chris
    
    
    > On Aug 22, 2018, at 12:02 PM, Russ Housley <[e-mail]> wrote:
    > 
    > Section 8, Order of Claim Keys, now says:
    > 
    >   The order of the claim keys MUST follow the rules of [RFC8225]
    >   Section 9 and be in lexixgraphic order.  Therefore, the claim keys
    >   MUST appear in the PASSporT Payload in the following order,
    > 
    >   o  attest
    > 
    >   o  dest
    > 
    >   o  iat
    > 
    >   o  orig
    > 
    >   o  origid
    > 
    > I assume that other extensions will be specified in the future,  so I am wondering if it would be better to say:
    > 
    > 8.  Order of Claim Keys
    > 
    >   The order of the claim keys MUST follow the rules of [RFC8225]
    >   Section 9; the claim keys MUST appear in lexicographic order.
    >   Therefore, the claim keys discussed in this document appear in
    >   the PASSporT Payload in the following order:
    > 
    >   o  attest
    > 
    >   o  dest
    > 
    >   o  iat
    > 
    >   o  orig
    > 
    >   o  origid
    > 
    > Russ
    > 
    > 
    >> On Mar 19, 2018, at 1:20 PM, Chris Wendt <[e-mail]> wrote:
    >> 
    >> Hi All,
    >> 
    >> I have updated the draft with some fixes based on comments from Christer, both editorial and related to ordering comments.
    >> 
    >> Summary of changes:
    >> 
    >> - addressing Christer’s comments around order of claims adding a brief new section
    >> - clarified the definition of “customer” in the PASSporT ‘attest’ claim section 4
    >> - clarified that it is calling party telephone number that is being attested to in same section
    >> - removed last sentence in section 7, it’s repetitive and not needed.
    >> 
    >> I figured i would include these changes and update document for efficiency, but will review these in meeting on Thursday in either case.
    >> 
    >> -Chris
    >> 
    >> 
    >> 
    >>> On Mar 19, 2018, at 5:12 PM, [e-mail] wrote:
    >>> 
    >>> 
    >>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
    >>> This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF.
    >>> 
    >>>      Title           : PASSporT SHAKEN Extension (SHAKEN)
    >>>      Authors         : Chris Wendt
    >>>                        Mary Barnes
    >>> 	Filename        : draft-ietf-stir-passport-shaken-02.txt
    >>> 	Pages           : 7
    >>> 	Date            : 2018-03-19
    >>> 
    >>> Abstract:
    >>> This document extends PASSporT, which is a token object that conveys
    >>> cryptographically-signed information about the participants involved
    >>> in communications, to include information defined as part of the
    >>> SHAKEN specification from ATIS (Alliance for Telecommunications
    >>> Industry Solutions) and the SIP Forum IP-NNI Joint Task Force.  These
    >>> extensions provide a level of confidence in the correctness of the
    >>> originating identity for a telephone network that has communications
    >>> coming from both STIR participating originating communications as
    >>> well as communications that does not include STIR information.
    >>> 
    >>> 
    >>> The IETF datatracker status page for this draft is:
    >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dstir-2Dpassport-2Dshaken_&d=DwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=ri4xF2qe2OXWXZ0N4IyxOWzytGeMXyH-W2Zqy0ns9Ss&s=qjlHabC1pKpu2a2pFkNEeqZ9J7vaYjKY4SQ5nSFA1ls&e=
    >>> 
    >>> There are also htmlized versions available at:
    >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dstir-2Dpassport-2Dshaken-2D02&d=DwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=ri4xF2qe2OXWXZ0N4IyxOWzytGeMXyH-W2Zqy0ns9Ss&s=SCxZ0SyqVgbPBT-G-_feprAQ9X4FY3_RTM5q6Y1oVAY&e=
    >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dstir-2Dpassport-2Dshaken-2D02&d=DwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=ri4xF2qe2OXWXZ0N4IyxOWzytGeMXyH-W2Zqy0ns9Ss&s=TqgXVpiW-_xqz-mfiaWHZ7_sEIzPekjEKGTNYLDCQBQ&e=
    >>> 
    >>> A diff from the previous version is available at:
    >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dstir-2Dpassport-2Dshaken-2D02&d=DwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=ri4xF2qe2OXWXZ0N4IyxOWzytGeMXyH-W2Zqy0ns9Ss&s=Q9Yr0YqYIbhK4t-me9Dw-CH6OlHzX1MKLR9C9zw9SeY&e=
    >>> 
    >>> 
    >>> Please note that it may take a couple of minutes from the time of submission
    >>> until the htmlized version and diff are available at tools.ietf.org.
    >>> 
    >>> Internet-Drafts are also available by anonymous FTP at:
    >>> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=ri4xF2qe2OXWXZ0N4IyxOWzytGeMXyH-W2Zqy0ns9Ss&s=V_dBXH2loc8aqrIpiStEdHQBS4UeARffuW_tyFM8fEo&e=
    >>> 
    >>> _______________________________________________
    >>> stir mailing list
    >>> [e-mail]
    >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=ri4xF2qe2OXWXZ0N4IyxOWzytGeMXyH-W2Zqy0ns9Ss&s=2A5wsjJ663GDHF4Kb2H3iISClAALpDzAi1h2y-NFh9k&e=
    >> 
    >> _______________________________________________
    >> stir mailing list
    >> [e-mail]
    >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=ri4xF2qe2OXWXZ0N4IyxOWzytGeMXyH-W2Zqy0ns9Ss&s=2A5wsjJ663GDHF4Kb2H3iISClAALpDzAi1h2y-NFh9k&e=
    > 
    
    _______________________________________________
    stir mailing list
    [e-mail]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=ri4xF2qe2OXWXZ0N4IyxOWzytGeMXyH-W2Zqy0ns9Ss&s=2A5wsjJ663GDHF4Kb2H3iISClAALpDzAi1h2y-NFh9k&e=