Subject: [CDNi] URI Signing URI Container Claim Question

From: Phil Sorber <[email-masked]>
Date: Tue, 9 Nov 2021 15:39:22 -0700

This is one of three questions that I had after last call feedback. I'd
like to hear any opinions on the matter from the working group. I will be
pointing to this thread for explanation/justification about the changes or
lack thereof to the document. Thanks.

Do we want to make the URI Container claim mandatory, or should we allow
certain "skeleton key" functionality, perhaps with additional text around
what you can do to make sure you don't give away keys to the kingdom, for
example making sure it has a reasonable expiry and perhaps a Client IP
claim to limit the blast radius?

---

From: Chris Lemmons <[email-masked]>
Date: Wed, 10 Nov 2021 00:32:50 -0700

There's no compelling reason to ask token issuers to put "cdniuc":".*"
in the token for a wildcard. It just wastes time on the processor as
it processes the unnecessary claim. I understand the concern that
unbounded claims can have undesirable security properties, though.
Perhaps some text in the Security Considerations could warn Token
Processors that they will need to be able to correlate acceptable
signing keys with sets of URIs (often via hostname, but
implementations will vary)?

On Tue, Nov 9, 2021 at 3:39 PM Phil Sorber <[email-masked]> wrote:
>
> This is one of three questions that I had after last call feedback. I'd like to hear any opinions on the matter from the working group. I will be pointing to this thread for explanation/justification about the changes or lack thereof to the document. Thanks.
>
> Do we want to make the URI Container claim mandatory, or should we allow certain "skeleton key" functionality, perhaps with additional text around what you can do to make sure you don't give away keys to the kingdom, for example making sure it has a reasonable expiry and perhaps a Client IP claim to limit the blast radius?
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Kevin Ma <[email-masked]>
Date: Wed, 10 Nov 2021 13:15:44 -0500

Hi Phil,

  I think I need a refresher.  Could you please add a link to the
discussion thread?  The URI container claim is to make the request URL
tamper evident?  But you would still need a valid signature without the
container verification?  Is the concern some type of replay attack?

thanx!

--  Kevin J. Ma

---

From: Phil Sorber <[email-masked]>
Date: Wed, 10 Nov 2021 11:47:03 -0700

Kevin,

Here is the reference in the doc:
https://www.ietf.org/archive/id/draft-ietf-cdni-uri-signing-22.html#name-cdni-uri-container-cdniuc-c

The only mailing list discussion I see is from Barry asking if the claim
should be mandatory or not.

The URI Container is what we match the request URI against. So not adding
it means the JWT will match any URI as long as that content is protected by
the key used to sign the JWT and any other claims included are satisfied.

So yes, including cdniuc makes the request URL tamper resistant and still
requires a valid signature even without it.

The concern is that if someone copies this token it can be widely used to
bypass URI signing protections. It's not scoped small enough without it.
That's why I think we suggest that this claim is used with an expiry and
also possibly Client IP. I'd prefer not to have a complex matrix of claim
combination requirements, but I also see none of them as so important that
they MUST be included in any valid JWT. Even if we did make it mandatory,
as Chris pointed out, the value can still be made effectively ".*" which is
the same problem but with extra steps.

Thanks.

---

From: Kevin Ma <[email-masked]>
Date: Wed, 10 Nov 2021 21:01:09 -0500

Hi Phil,

  Ah. right.  I see Barry's point.  The spirit of URI Signing is that it
covers a specific URI.  The original scheme (pre-JWT) hashed over the URI.
The regex was added when we added support for adaptive streaming.  The
original "path pattern" in the -04 version was mandatory, but we switched
it to optional (and changed the name to "pattern container") in the -06.
That was during the flip/flop around the KPN IP disclosure.  I don't
remember if the mandatory to optional change was intentional or not; Ray is
probably the only one who might remember.  But, I think making the
container claim mandatory is consistent with the intent of the protocol
(and the original implementation).  The fact that you could wildcard a
regex is in the same vein as using an infinite expiration, imo; i.e., it's
a bad idea and you shouldn't do it, but there's really nothing preventing
it.  I think I would side with making it mandatory and adding guidance to
not use a ".*" regex.

thanx!

--  Kevin J. Ma