Subject: [stir] WG LC Comments: draft-ietf-stir-oob-04

From: Eric Burger <[email-masked]>
Date: Tue, 16 Apr 2019 11:05:59 -0400

Section 11:
It looks like there was going to be a list of discovery requirements and considerations for credential discovery, but there’s just a blank space.  There is an element of “and then a miracle occurs” which is a bit disturbing.

Section 10 and Section 5.4:
Also “a miracle occurs” moment in how to find a CPS.

Section 6.1:
Where do the public keys come from? This also means lots of crypto work for the caller. This could be a benefit, namely requiring a proof of work to place a phone call. Although, it could be more efficient to charge some fraction of bitcoin in lieu of proof of work ;-)

Section 5.5:
This scheme totally fails for a call center or enterprise that just uses a single number for all (or many) outbound calls. They will all have the same source address.

Section 5.3:
Should note that the receiver will need to query every call that does not have a PASSporT attached.

Section 5.2:
Should note that the sender will have to deposit a PASSporT for *every* call placed. Likewise, the receiver will have to attempt to retrieve a PASSporT for *every* call received without a PASSporT attached.

Section 5.1:
Should note that the gateway will have to deposit a PASSporT for *every* call through the gateway, irrespective of receiver’s capabilities.

Section 14:
Should note this mechanism adds a ton of vectors for things to go wrong. As well, while the From identification is nominally encrypted, simple traffic analysis will give up most of the privacy provisions.

Nit: top of page 13:
OLD
PSTN mechanisms for relying a calling party
NEW
PSTN mechanisms for relaying a calling party

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 17 Apr 2019 23:27:04 +0000

Thanks for the notes Eric. Responses inline:

    Section 11:

<Jon>No, there wasn't supposed to be a list there, but I'll agree looking at the section the "like:" can make it look like there was supposed to be, I'll clip that. More on the substanative point in a sec...</Jon>

    Section 6.1:
    
<Jon>To this and the above two points, I don't really think there is any miracle required here. For the purposes of kicking the tires with OOB, manually provisioning of CPS's will work just fine. Moreover, STIR assumes a certain degree of pre-association with trust anchors, and it isn't too hard to imagine that certificate repositories, or pointers to same, could be managed by anyone running a trust root. The certs themselves could contain pointers to a CPS, as the draft already mentions. Magic not necessary.</Jon>

    Section 5.5:

<Jon>Fails what? That use case is describing inbound calls to a call center, not outbound calls from it. In any event, the point here is that there is a trade-off in running a high-volume notification service feed at a CPS: although you can argue it chips away at the privacy story, then again, merely knowing that a call is arriving at a high-volume call center might not reveal all that much. If your volumes are low enough that it might reveal something, perhaps you shouldn't be using a high-volume notification interface.</Jon>
    
    Section 5.3:
    
    Section 5.2:
    
    Section 5.1:

<Jon>To all three of the above, there could be deployments where that is or is not true. I don't think it is a requirement for OOB overall.</Jon>
    
    Section 14:
    
<Jon>In-band STIR adds the vector that your traffic might not go SIP end-to-end and thus STIR doesn't work, which is, well, a pretty big vector. Of course it's a trade-off. There are a number of countermeasures described in the document to thwart simple traffic analysis.</Jon>
    
    Nit: top of page 13:
    OLD

<Jon>Will fix. Thanks!</Jon>

---

From: Mary Barnes <[email-masked]>
Date: Thu, 18 Apr 2019 15:59:11 -0500

I'm in the process of completing my review and had a comment in section 14,
so I'd thought I'd just respond here rather than bring up separately [MB].

Regards,
Mary.

On Wed, Apr 17, 2019 at 6:27 PM Peterson, Jon <jon.peterson=
[email-masked]> wrote:

>     It looks like there was going to be a list of discovery requirements
> and considerations for credential discovery, but there’s just a blank
> space.  There is an element of “and then a miracle occurs” which is a bit
> disturbing.
>
> <Jon>No, there wasn't supposed to be a list there, but I'll agree looking
> at the section the "like:" can make it look like there was supposed to be,
> I'll clip that. More on the substanative point in a sec...</Jon>
>
>     Where do the public keys come from? This also means lots of crypto
> work for the caller. This could be a benefit, namely requiring a proof of
> work to place a phone call. Although, it could be more efficient to charge
> some fraction of bitcoin in lieu of proof of work ;-)
>
> <Jon>To this and the above two points, I don't really think there is any
> miracle required here. For the purposes of kicking the tires with OOB,
> manually provisioning of CPS's will work just fine. Moreover, STIR assumes
> a certain degree of pre-association with trust anchors, and it isn't too
> hard to imagine that certificate repositories, or pointers to same, could
> be managed by anyone running a trust root. The certs themselves could
> contain pointers to a CPS, as the draft already mentions. Magic not
> necessary.</Jon>
>
>     Section 5.5:
>     This scheme totally fails for a call center or enterprise that just
> uses a single number for all (or many) outbound calls. They will all have
> the same source address.
>
> <Jon>Fails what? That use case is describing inbound calls to a call
> center, not outbound calls from it. In any event, the point here is that
> there is a trade-off in running a high-volume notification service feed at
> a CPS: although you can argue it chips away at the privacy story, then
> again, merely knowing that a call is arriving at a high-volume call center
> might not reveal all that much. If your volumes are low enough that it
> might reveal something, perhaps you shouldn't be using a high-volume
> notification interface.</Jon>
>
>     Section 5.3:
>     Should note that the sender will have to deposit a PASSporT for
> *every* call placed. Likewise, the receiver will have to attempt to
> retrieve a PASSporT for *every* call received without a PASSporT attached.
>
>     Section 5.1:
>     Should note that the gateway will have to deposit a PASSporT for
> *every* call through the gateway, irrespective of receiver’s capabilities.
>
> <Jon>To all three of the above, there could be deployments where that is
> or is not true. I don't think it is a requirement for OOB overall.</Jon>
>
>     Section 14:
>     Should note this mechanism adds a ton of vectors for things to go
> wrong. As well, while the From identification is nominally encrypted,
> simple traffic analysis will give up most of the privacy provisions.
>
> <Jon>In-band STIR adds the vector that your traffic might not go SIP
> end-to-end and thus STIR doesn't work, which is, well, a pretty big vector.
> Of course it's a trade-off. There are a number of countermeasures described
> in the document to thwart simple traffic analysis.</Jon>
>

[MB] I was thinking something is missing from this section and perhaps
adding a statement in the same vain as your response could be helpful.
And, I think highlighting the potential for a DoS attack here might be
helpful.   [/MB]

> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 25 Apr 2019 22:04:30 +0000

[MB] I was thinking something is missing from this section and perhaps adding a statement in the same vain as your response could be helpful.  And, I think highlighting the potential for a DoS attack here might be helpful.   [/MB]

We can do that, no problem. Basically, we’d add some pointers to the earlier sections where those measures are discussed.

Jon Peterson
Neustar, Inc.