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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 11 Jun 2019 17:58:24 -0700

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

---

From: Eric Burger <[email-masked]>
Date: Wed, 19 Jun 2019 22:50:40 -0400

> On Jun 11, 2019, at 8:58 PM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
[snip]
> "many jurisdictions”?

I would prefer not to put it into an archival document. One might think the U.S. and Canada would be examples, but I cannot speak on behalf of the U.S. Government, Canadian Government, or any governmental department, agency, or commission.

[snip]
> window of time corresponding to the allowed RTT and any permitted time

Given the ubiquity of using iat for just this purpose, I would offer it would be redundant to reiterate it here. Would it be OK with you to not go there here?

> call as well; can we get into some sort of recursion-like situation?

That would be a major fail on the part of the intermediary. However, I do not think there is anything we can do about it. We certainly do not want to tell the intermediary operator they cannot protect themselves from, in this case, a TDoS attack. On the other hand, I do not think we can possibly require the intermediary operator to accept the call. That would be some magic Protocol Policing(tm) if we could! Because of the risks, I am not sure we even want to give guidance - such an operational issue seems outside the scope of the IETF. However, if the IESG or SIPCORE folks think otherwise, I can put in some language to that effect.

[snip]
I edited most all of your other comments in. Thanks!

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 19 Jun 2019 22:14:23 -0500

> I would prefer not to put it into an archival document. One might think the U.S. and Canada would be examples, but I cannot speak on behalf of the U.S. Government, Canadian Government, or any gover…

Understood.

> Given the ubiquity of using iat for just this purpose, I would offer it would be redundant to reiterate it here. Would it be OK with you to not go there here?

That would be okay, yes.

> That would be a major fail on the part of the intermediary. However, I do not think there is anything we can do about it. We certainly do not want to tell the intermediary operator they cannot prot…

Mostly I just wanted to check that I was understanding things properly;
I agree that would be a major fail by the intermediary.  So please don't
add any guidance solely on my account!

> I edited most all of your other comments in. Thanks!

Thanks!

-Ben