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

["Peterson, Jon" <[e-mail]>]

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 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.

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.