[stir] Re: AD Evaluation: draft-ietf-stir-rfc4916-update-05

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

Hi Orie,

Thanks for the review.  There’s a new version with these fixes. A few responses below inline.


I have only a few comments and several nits.
For the "stylistic nits", please feel free to ignore them.

I'm providing a corrected announcement to be sent from the writeup here (Russ feel free to make any additional corrections):

Technical Summary

   The SIP Identity header conveys cryptographic identity information
   about the originators of SIP requests.  However, the Secure Telephone
   Identity Revisited (STIR) framework provides no means for determining
   the identity of the called party in a traditional telephone calling
   scenario.  This document updates prior guidance to reflect changes to
   SIP Identity that accompanied STIR, and offers a way to tell the
   originator the "connected identity".  That is, the telephone number of
   the party that answered the call, even if the call was retargeted to
   party trying to impersonate the intended destination.

Working Group Summary

  The STIR WG reached consensus, and there is support for
  publication of this document as a standards-track RFC.

Document Quality

  Several people have expressed interest in implementing this
  specification.

Personnel

  Russ Housley is the Document Shepherd.
  Orie Steele is the Responsible Area Director.


## Comments

### Clarifying div requirements

```
293   This specification introduces another alternative.  When sending a
294   "rsp" PASSporT type in a SIP response, a UAS MAY also include (in
295   Identity header field values) any "div" PASSporTs it received in the
296   INVITE that initiated this dialog.  Thus, PASSporTs of type "div" MAY
297   also appear in SIP responses.  These "div" PASSporTs can enable the
298   originating side to receive a secure assurance that the call is being
299   fielded by the proper recipient per the routing of the call.  In this
300   case, the "dest" signed in the "rsp" PASSporT will be the address-of-
301   record of the party who was reached, rather than the "dest" of the
302   PASSporT received in the dialog-initiating INVITE.
```

Consider:

the "dest" signed in the "rsp" PASSporT MUST be the address-of-...

You’re correct, changed to MUST.

I also wonder if this paragraph could be rephrased to include a single MAY and then several MUST / SHOULDs.

I mean, as I read it, there’s normative language where it should be in this paragraph (apart from the fix you suggested above), the rest is really more descriptive.


I found it a bit difficult to grok, but I am not a SIP or STIR expert.


### Clarifying why SHOULD

```
343   limited to provisional dialog requests.  Once a dialog has been
344   established with connected identity, any re-INVITEs from either the
345   originating and terminating side, as well as any BYE requests, SHOULD
346   contain Identity headers with valid PASSporTs.  If only the
347   terminating side supports connected identity, obviously the
348   originator cannot be expected to know that it needs to send PASSporTs
349   for subsequent requests like BYE.  Doing so prevents third-parties
```

I think this reads as "SHOULD... unless only the terminating side supports connected identity..."

Is that right?

Yes that’s right.


The RECOMMENDED that follows this might be redundant, but I don't mind it.

Cool.


### can vs MUST

```
376   Mid-dialog requests also require special handling in diversion cases.
377   Relying parties who intended to trust an "rsp" PASSporT MUST validate
378   any "div" chain back to the "rsp" PASSporT on any Identity header
379   field values received in responses.  The dialog initiator can then
380   treat the certificate that signed that "rsp" PASSporT as the
381   appropriate certificate to sign any further mid-dialog or dialog-
382   terminating requests received in the backwards direction.
```

Is the dialog initiator required to treat the certificate that signed that "rsp" PASSporT... ?

Or is this "can" descriptive of the behavior implied by the MUST above?

The vague “can” on the originating side reflects the reality that it’s a policy decision about authorization on the originating side that determines how the cert will be treated there – phrasing it  that the originator MUST treat the cert that signed the “rsp” as “appropriate” sounds like we’re depriving the originator of the ability to not trust the cert because they don’t trust the root that issued it or whatever. Make sense?


For a non expert like myself, this could be clearer.

### MUST be opt-in

```
524   cases.  From a user experience perspective, this would likely work
525   similarly to current systems for sharing numbers, names, and even
526   pictures from calling parties to called parties -- users have
527   considerable control over that experience, and similarly for
528   connected identity this must be an opt-in choice for users.  In
```

Can this be a normative privacy requirement?

It's not really prescriptive of any bits-on-the-wire protocol behavior – this is more text about what sorts of configuration options a user might have on their UA (their phone or whatever), a sort of user experience matter that we don’t typically give normative guidance for in my experience at the IETF.


Perhaps we can seperate the user experience part from the opt in part, and make this stronger.

I’m not really sure how to do that – that is, how we can mandate that you MUST NOT use connected identity unless some user experience box has been ticked, because to do that we’d need to design the box. What qualifies as an adequate opt-in to permit connected identity? Those sorts of questions.

The nits below are fixed in the new -06 (along with the normative change above).

Thanks,

Jon Peterson
TransUnion



## Nits


### Expand on first use

PSTN, UAS, UAC, SRTP




```
165   Today, sophisticated adversaries can redirect calls on the PSTN to
166   destinations other than the intended called party.  For some call
```

```
293   This specification introduces another alternative.  When sending a
294   "rsp" PASSporT type in a SIP response, a UAS MAY also include (in
295   Identity header field values) any "div" PASSporTs it received in the
296   INVITE that initiated this dialog.  Thus, PASSporTs of type "div" MAY
```

```
370   response has been received from a UAS.  This specification does not
371   forbid a UAC from sending a CANCEL for its own PASSporT-protected
```

```
406   This is analogous to a situation where SRTP negotiation fails because
407   the keys exchanges at the media layer do not match fingerprints
```

### Would or might, not both

```
242   While it would might seem attractive to provide identity for failure
243   response codes (4XX, 5XX, 6XX), those explicitly do not form dialogs
244   or connections, and are thus outside the scope of this specification.
```

### sunny-day

Consider "basic" or "primary" alternatives which improve comprehension for international readers.

```
252   numbers are the identifiers used by the caller and callee.  For
253   sunny-day use cases, a PASSporT in a 183 or 200 OK should be
254   sufficient to secure media keys for the purposes of SIPBRANDY
255   [RFC8862].
```

```
495   However, the complexity of this mechanism makes it impractical to
496   deploy for both the "sunny day" use case and the diversion use case
```

### a different

```
307   received in a dialog-forming request with aidfferent "dest" value
```

### non normative may

```
309   used in responses. "div" is not universally supported, so calls may
310   be retargeted without generating a "div" PASSporT, in which case the
311   use of "rsp" PASSporTs will not be possible.  Note that the decision
312   to trust any "div" or "rsp" PASSporT is, as always in STIR, a matter
313   of local policy of the relying parties: some stricter systems may not
314   want to trust any "rsp" that differs from the "dest" in the PASSporT
315   of the original request.
```

Consider changing a few lower case "may" to "might" for better clarity here.

The ”may not want to trust” is again not bits-on-the-wire behavior but a policy decision – but the first MAY in “so calls may be” that should be normative.


### extra sent

```
367   Identity header with a PASSporT.  However, CANCEL requests can also
368   sent be sent by stateful proxy servers engaged in parallel forking;
```

### automata vs automated system

The word "automata" appears twice, where "automated system" might improve comprehension for international readers.

### his/their contributions

```
506   We would like to thank Russ Housley and Jonathan Rosenberg for his
507   contribution to this specification.
```

Regards,

OS, ART AD