Subject: Re: [stir] Stephen Farrell's Discuss on draft-ietf-stir-certificates-11: (with DISCUSS and COMMENT)

From: Richard Shockey <[email-masked]>
Date: Thu, 03 Nov 2016 16:08:30 -0400

On 11/3/16, 10:00 AM, "stir on behalf of Peterson, Jon" <[email-masked] on behalf of [email-masked]> wrote:

    >
    >(1) TN auth list services - IIUC, these are not free today.  Is
    >that correct?  It's not clear to me that alternatives such as
    >listing all good numbers inside a cert are practical.  Did the WG
    >have an explicit consensus that building in a requirement to have
    >verifiers pay to be an effective RP is ok?  If so, can you send a
    >pointer to the list archive or minutes where that was agreed. If
    >not, don't the WG need to explicitly ok that?
    
    Um, I think the most immediate plans for stir-certs deployment include
    just using SPIDs, in which case the TNs hardly factor into it. Agreed that
    listing all good numbers inside a cert is likely not practical, except for
    cases where a cert contains just a single number or a manageable block -
    and that's probably the second-most-immediate plan for deployment.

RS> Just to concur with Jon here the preliminary US Profile of STIR, which is called SHAKEN developed out of ATIS and the SIP Forum NNI Task Force, the claims are made by licensed service providers that have a NECA Operating Carrier Number (OCN) which is sort of a SPID. 

The basics of SHAKEN was reported to the FCC by the Industry robocall strikeforce. 

https://www.fcc.gov/news-events/events/2016/10/second-meeting-industry-led-robocall-strike-force

There are provisions in our profile for per TN assertions but at this preliminary point, it is only for highly specific applications.  Jon is correct that it is way way too soon to speculate further until there are some preliminary deployments. The good news this it will deploy though there may be national specific differences.  

    I don't think there is any real analog to the services required for
    fancier things here in the marketplace today. This'll be new. If it's done
    with OCSP, as the draft recommends, it'll cost about as much as OCSP does
    - which is a cost built into the certs, not a cost to relying parties. So
    in short, I'm not sure anyone is viewing this as a potential profit
    center. You'll note that some ACME-related drafts are starting to appear
    (draft-peterson-acme-telephone, say) which point in the likely direction
    this is all going.

RS> Well we’ll see about that.  
    
    But to be clear, I completely agree that you should not have to pay to be
    a verifier - I just don't think that's what the mechanism does.

RS> This is dependent on the particular national profile of how the standards deploy.  This is NOT IMHO a one size fits all. 

    >(2) setion 8: you need to say more clearly exactly what the
    >IA5String values in the extension map to in the JWT. I assume it's
    >the field names but you don't say. You need to say if this
    >extension can or needs to be critical.
    
    Already talking about this one separately...
    
    >
    >(3) section 9: you need to say whether this extension needs to be
    >or can be critical and where in the cert path it's allowed to be
    >and how to interpret things if >1 cert in the path has this
    >extension (if that's allowed, and if it is, then complexity awaits
    >us;-).
    
    This one I'll defer to Sean.
    
    >
    >(4) section 10: you need to pick one MTI method I think. Why is
    >that wrong? You nearly, but not quite, do. Why not just do it?
    
    We aren't confident enough to do it yet. We want to throw some ideas out
    there and try them in the marketplace. A lot of people are telling me they
    like short-lived certs for this; others like OCSP. OCSP will look more
    attractive if we figure out how to get stapling to work with SIP.
    
    I'd say we've got enough here that it's worth a PS and some
    implementation, but I'm interested to see how it goes.
    
    >
    >(5) section 10: don't you need to somehow define "short-lived"?
    >That could be defined as an RP-configurable value, but even if so,
    >I think you need to say that. Even if you do that, I'm not sure
    >that an RP-configured value is right as short-lived certs, vs.
    >not, puts a different burden on the signer and if the signer and
    >RP have different ideas of what short-lived means, then interop
    >failures seem likely. Bottom line for this point: what's a short
    >lived cert?
    
    Well, in this section a short-lived cert is largely a strawman discussed
    for rhetorical effect, not a fully-baked proposal. At the end of the
    section we say that the rest of the doc is going to explore the
    alternatives. Now again, I do think there are some good ideas about using
    short-lived certs for STIR, and I wouldn't be surprised if those were
    documented elsewhere. But for this baseline doc, we wanted to show an
    approach to doing status information. The jury's still out on which will
    turn out to be better.
    
    >
    >(6) section 10: as with short-lived, don't you need to define HVE?
    
    I would have thought the ref to RFC6960 was sufficient for at least
    defining it? That much said we're kind of just stealing ideas from HVE to
    build up our own profile.
    
    >
    >(7) section 10.2.1: Can OCSP be made use HTTPs here?  If not, then
    >you have the RP sending out the caller's TN in clear.  That seems
    >bad (cf. BCP188). Did the WG consider that? If this spec needs
    >OCSP/HTTPs then I think you need to have a new MUST for that (it's
    >uncommon or maybe never done?) and address the potential bootstrap
    >issues. (But I didn't think those through - did the WG?)
    
    I don't think we gave confidentiality for OCSP any serious consideration.
    At the very least that issue should be documented in the draft. If there's
    a reasonable fix, I'd be happy to use it - if it's breaking new ground,
    obviously that would take some doing.
    
    I'll respond to the comments below separately.
    
    Jon Peterson
    Neustar, Inc.

    [ (1) was the hard one, right? ]
    
    >
    >
    >----------------------------------------------------------------------
    >COMMENT:
    >----------------------------------------------------------------------
    >
    >
    >General - So a passport structure or SIP message can have a URI
    >for the cert. And the cert can have URLs for OCSP and AIA and for
    >a TN download service. That's potentially an awful lot of comms
    >out of the RP to do STIR. Has someone put all that together into a
    >usable assembly? If so, where's that documented? (To be open about
    >it, I was more of a fan of the DKIM starting point for this work,
    >but that's really just opinion, so this is definitely a
    >non-blocking comment.  I'd still be intersted in an answer
    >though.)
    >
    >- section 5: "Assignees of E.164 numbering resources participating
    >in this enrollment model should take appropriate steps to
    >establish trust anchors." That's ambiguous. Do you mean they
    >should establish a list of other folk's public keys they trust or
    >that they should generate their key pair and get their public key
    >on other folk's list of trust anchors?
    >
    >- section 7: What's the REQUIRED for EST about? That just seems
    >wrong.
    >
    >- section 10: SCVP? Really? Does anyone do that? I'd say get rid
    >of that text, it'll only cause grief.
    >
    >- section 10: "CRLs are an obviously attractive solution" hmm -
    >s/obviously/initially/ would seem more accurate.
    >
    >- 10.2: last two paras are speculative - do they belong in a spec
    >like this? If so, maybe re-word 'em so that they're not going to
    >confuse an implementer?
    >
    >
    
    _______________________________________________
    stir mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/stir

---

From: Dave Crocker <[email-masked]>
Date: Thu, 3 Nov 2016 13:34:42 -0700

> https://www.fcc.gov/news-events/events/2016/10/second-meeting-industry-led-robocall-strike-force

Basics.  Yes.  However...

Small point:

      The Shaken activities are by a relatively small, closed group, 
with results that are private, with no public access to the details and 
no ability to contribute.  Were Shaken merely an effort to provide some 
straightforward operational parameters, that might be fine.

      But getting STIR to be an functional service requires rather more 
than just agreeing to some parameters.

      So the public IETF STIR work is inadequate for creating a useful 
service, without the private, details specification work of Shaken.

d/

ps.  From a session at M3AAWG in Paris last week, I was promised that 
the Shaken specs would be made public.  I look forward to that.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Richard Shockey <[email-masked]>
Date: Thu, 03 Nov 2016 20:56:18 -0400

Fair point ..

We are working pretty hard to open up this process. These things take time negotiation lawyers etc.  

The SHAKEN Documents are here.  On a forward basis it’s the joint SIP Forum’s and ATIS plan to open up the process to as wide an audience as possible. More importantly the US telecom associations US Telecom and CTIA are opening up their process to all participants look at some of the other issues defined in the strike force report including the all-important track and trace issues.  We have to identify the networks that are injecting the malicious traffic into the network.  Looking at the existing CDR’s is just useless. 

If the IETF and the IESG can deliver this first phase of the protocols, then 3GPP and now DISPATCH can to their thing. The good news is STIR, at this stage will have wide adoption. It’s a fine set of tools. 

http://www.sipforum.org/content/view/439/312/

In case you hadn’t seen.

https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-callinfo-spam/

https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-status-unwanted

BTW IMHO these should be kept in DISPATCH and AD sponsored.  I will not support a new WG here. We have enough of those as it is. 

As you probably heard in Paris there is substantial interest in STIR/SHAKEN from multiple national jurisdictions and I will specifically be addressing some of those issues in the UK next week.

http://www.niccstandards.org.uk/meetings/forum-2016.cfm

In our defense the ATIS SIP Forum NNI TF has been looking at this for some time.  The strike force was under a very very short time line.   The strike force to the FCC enforced a non-disclosure agreement on this first phase of the work to outline what was possible and provide a roadmap to solutions.  You can argue one way or another on whether that was a good idea but in retrospect I could live with it and I was NOT a signatory to the NDA.  Lets try and keep a cooperative effort going.

— 
Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook rshockey101

PSTN +1 703-593-2683

On 11/3/16, 4:34 PM, "Dave Crocker" <[email-masked]> wrote:

    Basics.  Yes.  However...
    
    Small point:

    
    
    d/

    -- 
    
       Dave Crocker