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

[Eric Burger <[e-mail]>]

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