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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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://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-oob/



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