Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
A nontrivial amount of text in this document appears to have been taken from https://access.atis.org/apps/group_public/download.php/32237/ATIS-1000074.pdf which notes that "No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher." Do we have prior written permission to duplicate such text?
I am interested in seeing the resolution of discussion on Ekr's Discuss, but will stick to that thread for such discussion. Section 4 Am I reading this properly that the difference between 'A' and 'B' is that in 'B' we don't have any information about the device that's originating the call, just the identity of the user/customer?
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5207 I would like to discuss the privacy properties of origids. As I read this text, it does not actually require them to be unlinkable or that it not be possible to determine whether two ids represent the same person behind the origid generator, and I believe it should do so. Practically implementing that may require an ID that is longer than a UUID.
> > This document extends PASSporT, which is a token object that conveys > cryptographically-signed information about the participants involved > in communications. The extension is defined, corresponding to the > SHAKEN specification, to provide both a specific set of levels-of- > confidence to the correctness of the originating identity for a SIP Nit: confidence of or confidence in > in communications. The extension is defined, corresponding to the > SHAKEN specification, to provide both a specific set of levels-of- > confidence to the correctness of the originating identity for a SIP > based Communication Service Provider (CSP) telephone network > originated call as well as an identifier that allows the CSP to > uniquely identify the origination of the call within its network. Nit: originator S 1. > need to be accounted for where PASSporT signatures may represent > either direct or indirect call origination scenarios. The SHAKEN > [ATIS-1000074] specification defines levels of attestation of the > origination of the call as well as an origination identifier that can > help create a unique association with the origination of calls from > various parts of the VoIP or TDM telephone network. This document I can't read this. What is the association between? S 2. > capitals, as shown here. > > In addition, the following terms are used in this document: > > o Verified association: is typically defined as an authenticated > relationship with a device that initiated a call, for example, a relationship between the call and the device? S 4. > > o Has a direct authenticated relationship with the initiator of the > call and can identify the customer associated with the initiator. > > o Has NOT established a verified association with the calling party > telephone number being used for the call. For those who aren't; voice experts, can you give an example of when this would happen? S 10. > integrity protection and non-repudiation properties as the base > claims in the PASSporT. > > 10. Privacy Considerations > > As detailed in [RFC3261] Section 26, SIP messages inherently carry Thanks for including this section.
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
I echo Ben's "Yes assuming the Discusses can be resolved". It's about time we provided this capability! I did have a couple of comments you might want to consider, along with anything else that pops up during IESG Evaluation. "SHAKEN" isn't spelled out in either the title or Abstract - that would probably help almost all the readers of this document ... I did find it odd that This indicator allows for both identifying the service provider that is vouching for the call as well as clearly indicating what information the service provider is attesting to. The 'attest' claim can be one of the following three values: 'A', 'B', or 'C' as defined in [ATIS-1000074]. used "A", "B", and "C", instead of something like "F"(ull), "P"(artial), and "G"(ateway), because if you discover a need for a fourth value, it's not clear whether anyone would be assuming "A" < "B" < "C" ordering in their code, that would break if the fourth value was naturally between "A" and "B". If you're sure no one but Spencer would be so dumb, that's a fine response ...
I support Eric's DISCUSS. In addition to points made by Benjamin in that thread, I think if this document is going to say that threats introduced by origids "already existed in SIP," it also needs to talk about expectations for usage of origids in cases were existing SIP features to support anonymous calling are in use. Presumably callers who enable such features may also not expect their calling patterns to be linkable.