Re: [CDNi] URI Signing URI Container Claim Question

[Kevin Ma <[e-mail]>]

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

On Wed, Nov 10, 2021 at 1:47 PM Phil Sorber <[e-mail]> wrote:

> 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.
>
> On Wed, Nov 10, 2021 at 11:16 AM Kevin Ma <[e-mail]>
> wrote:
>
>> 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
>>
>> On Tue, Nov 9, 2021 at 5:39 PM Phil Sorber <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/cdni
>>>
>>