Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Let's discuss whether we need a standalone privacy considerations section. The document obviously does not ignore privacy, and in fact actively seeks privacy improvements in several places (encrypting PASSporTs to the recipient's key, blind-signatures for rate-limiting submission to the CPS, etc.), but it seems like a structured discussion that considers all the actors and the data flows amongst them might add significant value. Given the expected use of TLS and end-to-end PASSporT encryption, the direct leakage of call information to intermediaries/observers seems low, and the main risk is in metadata/correlation attacks that attempt to link submission to the CPS with initiation and reception of calls, with the CPS representing an entirely new potential attack point for learning about call information (in addition to the existing PSTN and SIP infrastructure). Some avenues for this have been closed off in the design/architecture presented, but I don't currently have confidence that all of them have been (to the extent that the cost/benefit tradeoff remains reasonable).
Section 5.2 After normal PSTN routing, the call lands on a smart mobile handset that supports the STIR out-of-band mechanism. It queries the appropriate CPS over the Internet to determine if a call has been How might "the appropriate CPS" be determined? (Is just linking to Section 10 the right thing to do?) Section 7.3 2. The attacker wishes to substitute himself for an existing call setup as described in Section 7.4. If an attacker can inject fake PASSporT into the CPS or in the communication from the CPS to the callee, he can mount either attack. As PASSporTs should be digitally signed by an appropriate authority for the number and verified by the callee (see Section 7.1), this should not arise in ordinary operations. For privacy and robustness Doesn't the substitution attack in the following section count as achieving (2)? And in general, couldn't an attacker always race with any legitimate call? Section 7.4 We don't specify what 111.555.1111 corresponds to before we use it in the example. In order to prevent a passive attacker from using traffic analysis or similar means to learn precisely when a call is placed, it is essential that the connection between the caller and the CPS be encrypted as recommended above. Callers could store dummy PASSporTs at the CPS at random intervals in order to make it more difficult for an eavesdropper to use traffic analysis to determine that a call was about to be placed. Not just encrypted, but potentially persistent, too? I guess that only makes sending the dummy traffic cheaper, but doing it non-persistently is not impossible. Section 7.5 We should note that K_cps should be limited to *only* be valid for signing these specific tokens, to avoid having a signing oracle that could be used for nefarious purposes. (Either here or in the security considerations.) Sign(K_cps, K_temp) Isn't this more of an "unblind" operation than a "sign" one, given that "Sender" shouldn't know K_cps? Section 9 The timestamps in these examples are kind of old at this point; do we want to refresh them to be closer to the time of publication? Assume that an authentication service has created the following PASSporT for a call to the telephone number 2.222.555.2222 (note that these are dummy values): eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InVyaSI6WyJz aXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI6IjE0NDMyMDgzNDUiLCJvcmlnI jp7InRuIjoiMTIxNTU1NTEyMTIifX0.rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1 VOgFWSjHBr8Qjpjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w Er, is the destination 2.222.555.2222 or sip:email@example.com? Having concluded the numbered steps in Section 8.1, including acquiring any token (per Section 6.1) needed to store the PASSporT at the CPS, the authentication service then stores the encrypted PASSporT: POST /cps/2.222.555.2222/ppts HTTP/1.1 Host: cps.example.com Content-Type: application/passport rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j Is it really appropriate to use the "application/passport" media type for an encrypted PASSporT? The web service assigns a new location for this encrypted PASSporT in the collection, returning a 201 OK with the location of /cps/188.8.131.522/ppts/ppt1. Now the authentication service can Should we consider the potential information leakage from sequential URL components? Perhaps randomized path components are better. Section 11 It is a desirable property that the public encryption key for a given party be linked to their STIR credential. We therefore propose that an ECDH [RFC7748] public-private key pair be generated for a subcert [I-D.ietf-tls-subcerts] of the STIR credential. That subcert could It seems a bit premature to phrase this as "We therefore propose" given that the rest of our speculative discusions have been generic in nature.
Thanks for the clarifications about why this is being published as an RFC. It would be good to document those in the shepherd write-up. Please respond to the Gen-ART review if this document moves forward.
Section 7.4. Per “Callers could store dummy PASSporTs at the CPS at random intervals in order to make it more difficult for an eavesdropper to use traffic analysis to determine that a call was about to be placed.”, given the different use cases and possible implementation strategies, I recommend using a different term that “callers” (since it sometimes might be gateways, a new kind of privacy devices which populates the CPS on behalf of a block of numbers it is supposes to protect, etc.). Section 7.5 Authenticate to CPS ---------------------> Blinded(K_temp) -------------------------> <------------- Sign(K_cps, Blinded(K_temp)) [Disconnect] Sign(K_cps, K_temp) Sign(K_temp, E(K_receiver, PASSporT)) ---> At an initial time when no call is yet in progress, a potential client connects to the CPS, authenticates, and sends a blinded version of a freshly generated public key. The CPS returns a signed version of that blinded key. The sender can then unblind the key and gets a signature on K_temp from the CPS. Recommend the following editorial clarifications to explain this flow: - s/and sends a blinded version of a freshly generated public key/and sends a blinded version of a freshly generated public key (i.e., K_temp)/ (maybe do that for other flow elements as well, or number the follows to allow easy reference in the text) - The K_cps depicted in the flow diagram is not explained in the text (i.e., the public key of the CPS?) - The K_receiver depicted in the follow diagram is not explained in the text - s/Sign(K_cps, K_temp)/Sign(K_cps, K_temp) ------------->/ - Somehow visual distinguish in the flow diagram that the signing key of “Sign(K_cps …)” is different than “Sign(K_temp, E(K_receiver …” Section 7.5. Per “Then later, when a client wants to store a PASSporT, it connects to the CPS anonymously (preferably over a network connection that cannot be correlated with the token acquisition)”, are there recommended strategies to realize non-attributed and attributed use cases across the use cases? Section 8.1. Per Step 2, this text provides an example of “out-of-band applications built-in to the calling device”, which covers only a subset of the use cases in Section 5 (i.e., UC1, 2 and 4?) Can anything be said about the other use cases? Section 9. Given that this document is notionally just laying out use cases, a high-level architecture, and high-level design considerations, this section seems to cross deep into a notional solution without all of the details outlined in the previous section. I would recommend removing it. * Editorial Nits: - Section 1. s/But while the core/While the core/ - Section 1. s/Then techniques/The techniques/ - Section 4. s/it is here specified generically/it is specified here generically/ - Section 7. Colloquial language. s/sketchy/vague/ - Section 7.4. Editorial. s/All that receipt/All the receipt/
I don't really understand why this document is requested to be published as informational and the shepherd write-up unfortunately doesn't provide any additional information about this decision, so I have to ask: I understand that the http-based protocol is meant only as an example protocol but how can such a scheme ever get deployed if there is not even a uniform protocol specified that a callee or caller can use to retrieve the needed information? If the group isn't sure about the the protocol selection yet, publishing this as experimental in order to get some experience with its deployment seems to be appropriate. However with the informational document right now (any only the example protocol), there is no guarantee for interoperability and I don't see how any test deployment could even happen. So what's the intention here?
Thank you for the work put into this document. BTW, I second Mirja's question about the doc status. Else, see below for minor COMMENTs. Regards, -éric == COMMENTS == -- Section 4 -- It is really unclear to me how the system could work if there is no discovery mechanisms for the CPS (even if section 10 is devoted to discovery). Else, I am fearing having one CPS per smart phone OS or any other fragmentation... -- Section 6 -- " transport-level security can provide confidentiality from eavesdroppers for both the storage", while I agree that TLS provides confidentiality for eavesdroppers, I wonder how it can protect the storage (data at rest) ? Or am I reading the sentence incorrectly ? -- Section 7.4 -- Should this section "Substitution Attacks" be a sub-section of section 7.3 "Security Analysis" ? In the time diagram, it is not clear at reading the figure what CS stands for (need to read the text below) also unclear who is initiating 'Call from CS': is it the attacker?