Re: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-oob-06: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Jon,

On Tue, Dec 10, 2019 at 12:46:14AM +0000, Peterson, Jon wrote:
> 
> Hello Benjamin,
> 
> Thanks for the read of the OOB doc. I'd be happy to add a standalone privacy considerations section before we advance the specification. I imagine it would largely point to discussions in other sections of the document, but I can see some value in also providing a general overview and comparison of the privacy properties of OOB versus traditional (in-band) STIR.

Thanks.  I also expect it to mostly reference discussions elsewhere in the
document, but it's hard to be sure until it's done :)

> Thanks as well for your other comments here, which I'll attempt to fix in the revision. Regarding the substitution attack in particular, attackers can race any call provided they know exactly when it has been placed, which is why there is proposed behavior dedicated to reducing the amount that attackers might learn about call placement from eavesdropping on the CPS. I think it's a difficult race to win even under the most favorable circumstances for the attacker. In any event, it requires a level of sophistication that is well beyond what people do to launch illegal spoofed robocalls today, which is the main thing we're trying to win relief from with the STIR work.

Definitely agreed that this makes spoofed robocalls much harder, and that
is something worth doing, and I do appreciate the measures to avoid/reduce
the leakage about call information.

-Ben

> Jon Peterson
> Neustar, Inc.
> 
> On 12/4/19, 9:18 PM, "Benjamin Kaduk via Datatracker" <[e-mail]> wrote:
> 
>     Benjamin Kaduk has entered the following ballot position for
>     draft-ietf-stir-oob-06: Discuss
>     
>     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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=Man2MO2PFEM9IaoJ9d4F7LJsQ7j_F8GMiWhI4r7BnDU&s=hA69wNIM9AmdI2CLrVG5h6K9NpyH8JbUx7oz_LH_tyk&e= 
>     for more information about IESG DISCUSS and COMMENT positions.
>     
>     
>     The document, along with other ballot positions, can be found here:
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dstir-2Doob_&d=DwICaQ&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=Man2MO2PFEM9IaoJ9d4F7LJsQ7j_F8GMiWhI4r7BnDU&s=HuM8zm-NwqAopn8eEK6qnKnmVnkycFjd_kOuQp_fx4E&e= 
>     
>     
>     
>     ----------------------------------------------------------------------
>     DISCUSS:
>     ----------------------------------------------------------------------
>     
>     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).
>     
>     
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>     
>     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:[e-mail]?
>     
>        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/2.222.222.2222/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.
>     
>     
>     
>