Subject: [stir] Ben Campbell's Yes on draft-ietf-stir-passport-shaken-05: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Tue, 20 Nov 2018 14:49:39 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-stir-passport-shaken-05: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-stir-passport-shaken/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am balloting "Yes" because I want to see the anti-robocalling framework get
deployed sooner than later. But I share some of the privacy concerns that have
been raised by others. I will follow that conversation on the thread resulting
from Ekr's DISCUSS.

Some additional comments:

*** Substantive Comments ***

§3: "The second claim is a unique origination identifier that should be
used by the service provider..."
Was that "should" meant as a "SHOULD"?

§4
- Some of the terminology in the definitions of the attestation types seems
vague to me.  Does "authenticated relationship with the initiator" mean the
same as "has authenticated the originator of the call"? Does "established a
verified association with the calling party telephone number" mean the same as
"verified that the calling party has the right to use the calling identity"?
(The ATIS doc has more detailed explanations, which makes me wonder if it
wouldn't have been better to just reference those definitions.)

- The type "C" description includes "Has no relationship with the initiator of
the call (e.g., international gateways)" in the list of MUST conditions. Is it
the intent that an operator can only use a Type C attestation if it does not
have that relationship? That is, an operator that did have a relationship with
the initiator of the call is not allowed to use a type C attestation to avoid
disclosure of the relationship? (How would one test that?)

§10:
- As Alissa mentioned, the fact that similar information that might be gleaned
from originid is carried in SIP is not very convincing. It's historically been
common for operators to use SBCs to hide things like Record-Route and Via. (and
I presume History-Info).

- Is originid required? Could an operator who had privacy concerns simply
choose not to include it? (Maybe that operator has sufficient internal records
to hunt down bad actors.)

- The ATIS doc talks about using the originid in type B attestations to track
"reputation". I assume this sort of tracking could be done by parties other
than the attesting operator? If so, I think that's worth some discussion.

*** Editorial Comments ***

- Abstract: Please expand SHAKEN in the abstract.

§1: Please expand VoIP, TDM, and SS7