Subject: [CDNi] Error Redirect for URI Signing

From: Chris Lemmons <[email-masked]>
Date: Sat, 3 Nov 2018 17:14:49 +0700

I've got a draft of some potential language for an error handling
claim in URI Signing. This came as a result of another attempt at an
implementation. The content originator wants to set a custom redirect
for when a token is out of date or otherwise invalid so the user agent
can go get a new token.

There are a number of use cases for it, so I think this might be the
simplest solution. I don't like having a separate claim for the error
code, but it is quite simple to implement and understand.

Thoughts?

Link: https://github.com/PSUdaemon/URISigningSpec/pull/56

---

From: Kevin Ma <[email-masked]>
Date: Tue, 6 Nov 2018 02:20:12 -0500

Hi Chris,

  (As a chair) My initial thoughts on the PR is that it doesn't really
address a CDNI issue.  What a CSP might want a UA to do when token
validation fails is not really in scope of CDNI, and can be handled other
ways by the UA (without bloating the token)?

  (As an individual) The proposed feature seems to make inter-CDN
interoperability for URI signing more complex (and that would need to be
fleshed out more and reflected in the sequence diagrams in Section 5).  I'm
not sure that I see the benefit (over letting the client implement 403
handling), without a more concrete use case.

thanx.

--  Kevin J. Ma

On Sat, Nov 3, 2018 at 6:15 AM Chris Lemmons <[email-masked]> wrote:

> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>

---

From: Phil Sorber <[email-masked]>
Date: Sun, 11 Nov 2018 21:15:43 -0700

(as an individual)

I'm not thrilled with the level of complication this adds. Not only will
you have to have a full URL to redirect the user to on error, but you will
have to capture enough state in the signed token to also redirect them back
and presumably to the point in the token sequence that they already were as
the intent here is to appear seamless. I can think of a few ways to do
this, but none of them seem good.

   1. Have the server append the request URL in some fashion to the
   redirect URL
   2. Have the destination of the redirect parse the referrer URL
   3. Let the client decide based upon what it may already have stored or
   in cache. This seems a bit hand wavy and we should provide some guidance to
   implementers. This also might be incompatible with things like HLS?

Is there another solution that you might propose? We should probably
include that in the text as a suggested implementation even if there is
nothing extra the server or client needs to do.

This will also make the token even bigger and I suspect very few will
implement it because of that.

If we adopt this, I think we should condense this to one claim. The space
is already polluted enough.

(as document editor)

We also need to have a registry entry for this.

Thanks.

---

From: Chris Lemmons <[email-masked]>
Date: Mon, 12 Nov 2018 15:16:32 -0700

Certainly, if you control the client entirely, you can easily specify
whatever behaviour you want. Likewise, it's possible to negotiate
special behaviour (which might or might not perfectly comport with the
URI Signing draft) if you only have one CDN to deal with. But if
you've got multiple CDNs or CDNs interconnected, it's desirable for a
signer to be able to specify the error return in the case of an
expired or otherwise invalid token. If you're not in a CDNI
environment, this isn't as critical of an issue.

You do bring up a potential point, which is "if a uCDN redirects to a
dCDN, should an error redirect that points somewhere on the uCDN also
be rewritten for the dCDN?" I guess that might be nice, but it
significantly complicates things. Instead, I would expect the client
to re-traverse the uCDN and be directed the appropriate resource via
normal channels.

Re: token bloat. There are a few ways to reduce the size of the token,
but I think simplicity is more important. If an entity controls both
the provider and the user agent, they don't necessarily need this sort
of bloat. But if they do need it, there's no real way around it.

Inter-CDN interop shouldn't be affected, unless I've missed something.
The error redirect target doesn't necessarily even need to be part of
the same CDN infrastructure, and if it is, it can use the same process
as any other content.

In terms of the benefit, it means that if either an origin or uCDN is
signing uris to let dCDNs know that the request is authorized, they
can also encode enough information to let the dCDN provide fallback
addresses for requests that fail.

For example, if a uCDN directs all requests from a particular network
to a dCDN, it may wish to sign it's redirections so that users that
have not been redirected there cannot retrieve content from the dCDN.
If a user agent retrieves a 302 redirect to the dCDN, but then
experiences a delay before resolving the dCDN's content, the dCDN may
reject the token as expired. If the dCDN responds with a 403, the
client is done and gets no data. If the dCDN responds with a redirect
back to the uCDN, it can re-evaluate the location, sign a new token,
and send the client back to obtain success. (Such a uCDN is advised to
be careful to avoid loops, in the event of a permanently incorrect
token being issued, of course.)

In another situation, a content origin may use a separate cookie or
another mechanism to keep track of authorizations. They can hand out
short-lived tokens and direct generic clients one or more CDNs, but
specify a redirect that goes back to the (perhaps comparatively more
expensive) origin-verification.

The weakest use case is streaming video, since the redirect won't have
enough information about the specific URI that was requested in order
to actually fulfill the request. Solutions to this scenario are rather
significantly more complex and are probably not worth it. Things like
trying to add the URI as query strings or similar wind up causing more
problems than they solve, I think. Technically, I think you could do
it with a template system: "cdnierr":
"http://fallback.example.com/r?failed=$uri_base64&reason=$err_code".
That's clearly powerful... but also requires a parsing engine,
complete with escapes. But it's hard to beat the simplicity of "Put
this value, unmodified, in the Location header and return this status
code".

As noted, if we like the idea, we also need a registry entry or two
for it, and probably an example.
On Tue, Nov 6, 2018 at 2:20 PM Kevin Ma <[email-masked]> wrote:
>
> Hi Chris,
>
>   (As a chair) My initial thoughts on the PR is that it doesn't really address a CDNI issue.  What a CSP might want a UA to do when token validation fails is not really in scope of CDNI, and can be handled other ways by the UA (without bloating the token)?
>
>   (As an individual) The proposed feature seems to make inter-CDN interoperability for URI signing more complex (and that would need to be fleshed out more and reflected in the sequence diagrams in Section 5).  I'm not sure that I see the benefit (over letting the client implement 403 handling), without a more concrete use case.
>
> thanx.
>
> --  Kevin J. Ma
>
>

---

From: "Matthew A. Miller" <[email-masked]>
Date: Mon, 12 Nov 2018 16:55:56 -0700

This proposal does not discuss redirect loops at all, which is a serious
concern.  There is a real potential for a UA to be stuck in a endless
loop of redirects.

Also, why is this preferred over some form of implementation-specific
agreement between the signer and verifier?  In order to validate the
signature, the verifier must have already established trust with the
signer through some means; why is that not appropriate to extend for
this type of enhanced behavior?

- m&m

Matthew A. Miller
On 18/11/11 21:15, Phil Sorber wrote:
> you have to have a full URL to redirect the user to on error, but you
> will have to capture enough state in the signed token to also redirect
> them back and presumably to the point in the token sequence that they
> already were as the intent here is to appear seamless. I can think of a
> few ways to do this, but none of them seem good.
> 
>     in cache. This seems a bit hand wavy and we should provide some
>     guidance to implementers. This also might be incompatible with
>     things like HLS?
> 
> If we adopt this, I think we should condense this to one claim. The
> space is already polluted enough.
> 
> (as document editor)
> 
> On Sat, Nov 3, 2018 at 4:15 AM Chris Lemmons <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Kevin Ma <[email-masked]>
Date: Tue, 13 Nov 2018 00:57:20 -0500

> Certainly, if you control the client entirely, you can easily specify
whatever behaviour you want.  [...]  it's desirable for a
signer to be able to specify the error return in the case of an expired or
otherwise invalid token.  [...]  If the dCDN responds with a redirect back
to the uCDN, it can re-evaluate the location, sign a new token, and send
the client back to obtain success.

I feel like most applications have some level of intelligence on the client
side, but for the sake of argument, assuming there is an application that
relies on this redirect, automatically doing something about an
expired/invalid token, e.g., generating a new valid token, seems to defeat
the purpose of having the token, unless there are deeper checks being
performed; and if there are deeper checks being performed, it seems to
place some (not well defined) responsibility on the CDN to perform those
deeper checks?

Do you anticipate only the CSP populating the cdnierr and cdnirc claims and
all CDNs use the same redirect?  Or do you see any/all CDNs along the way
being able to change the cdnierr and cdnirc claims?  If the latter, do you
see the need to be able to limit that in some way and/or set rules on which
CDNs can or cannot change the cdnierr and cdnirc claims?  If there are no
limitations on which CDNs can change the cdnierr and cdnirc claims and/or
perform the checks necessary to authorize issuing a new token, it's not
clear to me, from an interoperability perspective, how a given CDN in the
chain will know what it can/should do with these claims?

---

From: Chris Lemmons <[email-masked]>
Date: Tue, 13 Nov 2018 10:14:37 -0700

> If there are no limitations on which CDNs can change the cdnierr and cdnirc claims and/or perform the checks necessary to authorize issuing a new token, it's not clear to me, from an interoperability perspective, how a given CDN in the chain will know what it can/should do with these claims?

Ah, yeah. I didn't put that text in, but I expected that CDNs MUST NOT
change the cdnierr claims when redirecting. Everything else goes
outside of interoperability, which is fine, but then subject to
negotiation between the signer and CDN.

> Do you anticipate only the CSP populating the cdnierr and cdnirc claims and all CDNs use the same redirect?

Depends on the particular use case. In the simplest use case, where a
uCDN is redirecting clients based on geolocation or network
information, a client might change IPs, wait too long, or retry a
request after a nonce has been used. In such a case, recovery is
simple, just go back to the uCDN and let geolocation do it's thing.
This use case will mean that the signer (in this case, the uCDN), will
put the URL of the unredirected request (plus a tag that allows it to
detect loops, which should definitely be clarified in the text), in
the cdnierr.

In the case where the CSP is using it to authorize a client for CDN
resources (potentially on one or more CDNs, possibly stacked) that
already has a session on the CSPs server, the CSP may be happy to
re-issue tokens to a client that has one that no longer works. It will
use the same mechanism it used in the first place, probably a session
cookie, to verify that the client is authorized, then send them back
to the CDN for the actual content. This back-and-forth isn't
necessarily ideal, but could allow a CSP to use a more restrictive
token policy, safe in the knowledge that if the the client changes IP
or pauses for too long, or otherwise winds up with a bad token, they
can just redirect through the CSP's servers to get a new one. In this
case, the CSP is likely to use an endpoint locally that redirects to
the CDN, probably the same endpoint they used originally to reference
the content.

In the case where the CSP is using it to provide "fallback" content,
they might use a static value. For example, if the content to be
distributed is media thumbnails, the CSP might prefer that if a token
is invalid, the user be redirected to a generic image instead of
getting a blank field. In a custom app, this behaviour can be
implemented directly, but using standard status codes and redirections
allows the browser to simply take charge. If the CSP has a single CDN,
they can reasonably negotiate this behaviour, but in an interconnected
context, it's better to put the CSP in the driver's seat, I think.

> this type of enhanced behavior?

You're right that we don't need to specify all possible implementation
options here. But we should specify implementation options that will
impact interoperability. In this case, a signer cannot use this claim
unless it's supported by every CDN it uses. That argues for
standardization.

... but doesn't necessarily argue for standardization immediately. I'm
starting to be of the mind that the implications this claim are
complex enough to really require implementation experience before we
really standardize it. We can reasonably easily add claims in future
documents, if we so choose. The already extant crit claim gives us the
required compatibility as well. Is there a compelling reason we
shouldn't table this, ideally get some implementation experience
around it, then bring it back if experience warrants?
On Mon, Nov 12, 2018 at 10:57 PM Kevin Ma <[email-masked]> wrote:
>
> > Certainly, if you control the client entirely, you can easily specify whatever behaviour you want.  [...]  it's desirable for a
> signer to be able to specify the error return in the case of an expired or otherwise invalid token.  [...]  If the dCDN responds with a redirect back to the uCDN, it can re-evaluate the location, sign a new token, and send the client back to obtain success.
>
> I feel like most applications have some level of intelligence on the client side, but for the sake of argument, assuming there is an application that relies on this redirect, automatically doing something about an expired/invalid token, e.g., generating a new valid token, seems to defeat the purpose of having the token, unless there are deeper checks being performed; and if there are deeper checks being performed, it seems to place some (not well defined) responsibility on the CDN to perform those deeper checks?
>
> Do you anticipate only the CSP populating the cdnierr and cdnirc claims and all CDNs use the same redirect?  Or do you see any/all CDNs along the way being able to change the cdnierr and cdnirc claims?  If the latter, do you see the need to be able to limit that in some way and/or set rules on which CDNs can or cannot change the cdnierr and cdnirc claims?  If there are no limitations on which CDNs can change the cdnierr and cdnirc claims and/or perform the checks necessary to authorize issuing a new token, it's not clear to me, from an interoperability perspective, how a given CDN in the chain will know what it can/should do with these claims?
>
>
>