Secure Telephone Identity Threat Model
RFC 7375

Note: This ballot was opened for revision 03 and is now closed.

(Richard Barnes) Yes

Alissa Cooper Yes

Comment (2014-07-08 for -03)
No email
send info
I agree with Benoit's comment about Section 4.1. The attacks listed should either be further elaborated or the list should be removed.

(Spencer Dawkins) Yes

Comment (2014-07-10 for -03)
No email
send info
I'm a yes, and found the document mostly well-written and helpful. Let's start with that.

I agree with Benoit's point about the list of attacks with no details. 

In addition, the document title sounds like it's a complete analysis of STIR threats, but if I'm reading it correctly, there are a number of threats that aren't being considered (because the threats related to robocalling are considered to be the major concerns, did I get that right?).

You might want to consider adjusting the document title a bit to reflect that.

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Benoît Claise) No Objection

Comment (2014-07-07 for -03)
No email
send info
Not sure what the following text adds to the document. Either there is too much or too little information. 
I have no idea what some of these attacks mean:

   Some of the attacks that should be considered in the future include
   the following:

   Attacks Against In-band

      Token replay

      Baiting a call to a chosen number with a REFER

      Removal of in-band signaling features

   Attacks Against Out-of-Band

      Provisioning Garbage CPRs

      Data Mining

   Attacks Against Either Approach

      Attack on directories/services that say whether you should expect
      authenticated calling number data or not

      Canonicalization attacks

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-07-10 for -03)
No email
send info
- section 1, last para: I'm glad the names stuff is out of
scope, thanks.

- 2.3, 2nd last para: I don't get why an attacker who
compromises an intermediary is out of scope here. Do you only
mean within the PSTN though? (Which I'd understand.) The last
sentence there is also ambiguous - I think the countermeasures
you mean are those to be defined by STIR, but that isn't what
is stated.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Kathleen Moriarty) No Objection

Comment (2014-07-09 for -03)
No email
send info
The draft was an interesting read, thanks for your work on it to develop the threat models.  I just have some questions from thinking about a few of the discussion point and not being familiar with the controls currently in place, so please bear with me (all non-blocking questions/comments):

In Sect 3.2, The following seems odd to me, wouldn't the robocall program know to avoid numbers that raise suspicion and why aren't they just blocked outright as source numbers?
   A robocaller may impersonate
   a number that is not an assignable number (for example, in the United
   States, a number beginning with 0),

Beyond checking that a number is valid, is there really much that can be done?  If there is some sort of validation check against incoming numbers, helpful robocalling or texting could be blocked (local robocalls for storms, airlines notifying on changes, etc.).  Source numbers can change, if you block based on an unknown source (maybe something you have not subscribed to receive), you may miss something important.  If someone has not opted out (asked to not receive unsolicited calls), in the US at least, nothing prevents the caller from placing the call (legally).  Is anything changing on that or are we bound to those restrictions?

I'll also watch for a response to Benoit's comments.  Thanks.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection