[stir] Roman Danyliw's No Objection on draft-ietf-stir-oob-06: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-stir-oob-06: No Objection

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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/