[sipcore] Benjamin Kaduk's No Objection on draft-ietf-sipcore-rejected-08: (with COMMENT)

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

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sipcore-rejected-08: 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-sipcore-rejected/



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

Do we want to give any references/examples for "some jurisdictions" or
"many jurisdictions"?

Section 1

                     An algorithm can be vulnerable to an algorithm
   subject to the base rate fallacy [BaseRate] rejecting the call.  [...]

nit: It sounds like these are different algorithms, so that "One
algorithm can be vulnerable to a separate algorithm, subject to the base
rate fallacy, erroneously rejecting the call" would be more clear.

Section 3.1

   If there is a Call-Info header field, it MUST have the 'purpose'
   parameter of 'jwscard'.  The value of the Call-Info header field MUST
   refer to a valid JSON Web Signature (JWS [RFC7515]) encoding of a
   jCard [RFC7095] object.

Do we need to say anything about what entity('s key) generates the
signature and/or what affects signature algorithm selection (e.g.,
a forward reference to Sections 3.2.x)?

Section 3.2.2

   The payload contains two JSON values.  The first JSON Web Token (JWT)
   claim that MUST be present is the iat (issued at) claim [RFC7519].
   The "iat" MUST be set to the date and time of the issuance of the 608
   response.  This mandatory component protects the response from replay
   attacks.

nit(?): Perhaps this protection is only "outside the scope of a narrow
window of time corresponding to the allowed RTT and any permitted time
skew", per Section 3.3.

                                      Call originators (at the UAC) can
   use the information returned by the jCard to contact the intermediary
   that rejected the call to appeal the intermediary's blocking of the
   call attempt.  What the intermediary does if the blocked caller
   contacts the intermediary is outside the scope of this document.

It seems like it is permissible for the intermediary to reject this new
call as well; can we get into some sort of recursion-like situation?

Section 3.5

                              However, if the INVITE only indicated a
   real-time text codec and the network element can render the
   information in the requested media format, the network element MUST
   send the information in a text format, not an audio format.

This usage of 2119 language seems odd to me, like it's calling out a
single special case for normative treatment but ignoring the general
case.

Section 4.1

                                                   As such,
   implementations MUST NOT insert line breaks into the base64url
   encodings of the JOSE header or JWT.  This also means UACs MUST be
   prepared to receive arbitrarily long octet streams from the URI
   referenced by the Call-Info SIP header.

These (especially the MUST NOT) seem to just be restating requirements
from elsewhere and would not ordinarily need normative language to do
so.

Section 6

   Another risk is for an attacker to flood a proxy that supports the
   sip.608 feature with INVITE requests that lack the sip.608 feature
   capability to direct the SDP to a victim's device.  [...]

This sentence is pretty long/convoluted and could probably be reworded
for clarity.

   Yet another risk is a malicious intermediary that generates a
   malicious 608 response with a jCard referring to a malicious agent.
   For example, the recipient of a 608 may receive a TEL URI in the
   vCard.  When the recipient calls that address, the malicious agent
   could ask for personally identifying information.  However, instead
   of using that information to verify the recipient's identity, they
   are phishing the information for nefarious ends.  As such, we
   strongly recommend the recipient validates to whom they are
   communicating with if asking to adjudicate an erroneously rejected
   call attempt.  Since we may also be concerned about intermediate
   nodes modifying contact information, we can address both issues with
   a single solution.  The remediation is to require the intermediary to
   sign the jCard.  [...]

The signature is not a panacea -- the recipient needs to verify that the
signature comes from a trustworthy (in some sense) entity, and that the
person they contact based on the jCard is the same entity or affiliated
with the entity that generated the signature.  I think this is not quite
the same thing as the SHAKEN/SHAKEN-like mechanisms for validating that
the signing entity matches the called entity that are mentioned in the
subsequent text.

                  However, if the intermediary does go that route, the
   intermediary MUST use a non-deterministic reference mechanism and be
   prepared to return dummy responses so that attackers attempting to
   glean call metadata by guessing calls will not get any actionable
   information from the HTTPS GET.

Thanks for mentioning this side channel!  I'd suggest to clarify that
the dummy responses are in response to URIs that might be (but are not)
URIs that would be found in the "url" field of the jCard.  (Assuming I'm
understanding the attack correctly, of course.)