Subject: [CDNi] MPEG & Chained tokens

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 25 Mar 2015 19:36:00 +0000

Ray talked about chained signed tokens and I wondered if using asymmetrically encrypted tokens would solve the use case?

All dCDNs could decrypt the token contents (they are in the clear today) using public keys but only the generator of the token could create a token and there are no issues of sharing shared secrets between CDNs?

Or do the chained tokens solve additional issues I've missed?

Ben

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 25 Mar 2015 20:45:17 +0000

Hi Ben,

The current URI Signing draft already includes support for both symmetric hashes as well as asymmetric encryption of tokens/URIs. If the tokens were not hashed/encrypted, a UA would be free to adjust the expiration time in them, thereby negating the use of any signature in the first place. 

The main issue solved by the chained tokens concept is not so much how the token is encrypted, but how to make sure that I can give my manifest/MPD to an illegitimate client and he can fetch content from the CDN. By having a chain of tokens, each with a short expiration time, you reduce this vulnerability in the same way that existing URI Signing does this for regular (non-segmented) content. 

Best regards,

Ray

On 25/03/15 14:36, "Ben Niven-Jenkins" <[email-masked]> wrote:

>_______________________________________________
>CDNi mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cdni
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 25 Mar 2015 22:58:02 +0000

Ray,

Having a path_pattern attribute to allow a uCDN/Content Provider to have a token match multiple URLs is sensible and something that's used by CDNs today. That solves the segmented content case I believe.

The chained tokens I don't see how they add material benefit over a token with a long expiry time. If someone can share a manifest, they can share a URL for a video segment. Tokens were originally used to avoid people being able to download large files they couldn't play or install, etc. that the content provider had to pay for. They're not a substitute for DRM'ing content to prevent unauthorised playout.

Ben

> On 25 Mar 2015, at 20:45, Brandenburg, R. (Ray) van <[email-masked]> wrote:
> 
> Hi Ben,
>

---

From: "Thomas, E.D.R. (Emmanuel)" <[email-masked]>
Date: Thu, 26 Mar 2015 07:37:32 +0000

Dear Ben, Ray,

	I am Emmanuel Thomas from TNO, a colleague of Ray. I am actually coordinating the effort from MPEG concerning the use of URI Signing, and its possible improvements, in MPEG DASH.

	If I may comment on your remark : " Tokens were originally used to avoid people being able to download large files they couldn't play or install, etc. that the content provider had to pay for. They're not a substitute for DRM'ing content to prevent unauthorised playout."

	Today in MPEG, people are also working on methods to enable playback control of DASH clients. Needless to say that the non-normative nature of DASH client behaviors makes difficult to enforce such a control from the client side. However, one way to control what a DASH client may or may not playback is to control the delivery of the segments in the first the place. Hence being sure that a specific content is not going to be played out. And this decision can be motivated by business rules or any other context. So using DRM for that purpose wouldn't be appropriate because the client has the right to watch the content (e.g. he paid for it) but he just needs to perform certain actions first in order to retrieve the content (e.g. retrieve an ad). 

Regards,
Emmanuel 

-----Original Message-----
From: CDNi [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: woensdag 25 maart 2015 23:58
To: Brandenburg, R. (Ray) van
Cc: [email-masked]
Subject: Re: [CDNi] MPEG & Chained tokens

Ray,

Ben

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 26 Mar 2015 11:06:34 +0000

Hi Ben,

The chained tokens I don't see how they add material benefit over a token with a long expiry time. If someone can share a manifest, they can share a URL for a video segment.

The latter part of your argument, the fact that it is quite easy to share a URL, is exactly the reason why a token with a long expiry time doesn't work.

It is a lot easier to share a URL with a validity time of 90 minutes than one that is only valid for 10 seconds. To be honest I don't see any benefit of using any token or signed URI if it is going to have a long expiration time (in the order of minutes or more).

They're not a substitute for DRM'ing content to prevent unauthorised playout.

Completely agree.

Ray

On 25 Mar 2015, at 17:58, Ben Niven-Jenkins <[email-masked]<mailto:[email-masked]>> wrote:

Ray,

Ben

On 25 Mar 2015, at 20:45, Brandenburg, R. (Ray) van <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ben,

Best regards,

Ray

On 25/03/15 14:36, "Ben Niven-Jenkins" <[email-masked]<mailto:[email-masked]>> wrote:

Ben

_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 26 Mar 2015 17:32:11 +0000

Hi Emmanuel,

  I'm not sure I understand your argument, but access tokens are not a good method for "being sure that a specific content is not going to be played out."  That's why we have DRM.  Access tokens are about download, not playout.  (And of course using access tokens as DRM is impractical: short expirations fail when you support pause/rewind or even simple network delays; long tokens do not prevent reply; client addresses are inaccurate for shared devices and NAT'd networks; etc.)

  When you say "business rules," are you talking about the content provider, or the CDN provider?  CDN providers may want to use tokenized URLs to prevent bandwidth denial of service attacks (though it may arguably make request router denial of service attacks easier), but content providers can't reasonably rely on tokenized URLs to enforce licensing agreements, imo.

  To Ben's point, access tokens protect the CDN provider, and in turn the content providers who pay the CDN providers, from unnecessary delivery costs.  Access tokens do not provide DRM or reasonable playout control  against (un)licensed viewers.

thanx.

--  Kevin J. Ma

> From: CDNi [mailto:[email-masked]] On Behalf Of Thomas, E.D.R.
> (Emmanuel)
> Sent: Thursday, March 26, 2015 3:38 AM
> To: Ben Niven-Jenkins; Brandenburg, R. (Ray) van
> Cc: [email-masked]
> 	I am Emmanuel Thomas from TNO, a colleague of Ray. I am actually
> coordinating the effort from MPEG concerning the use of URI Signing, and its
> possible improvements, in MPEG DASH.
> 
> 	If I may comment on your remark : " Tokens were originally used to
> avoid people being able to download large files they couldn't play or
> install, etc. that the content provider had to pay for. They're not a
> substitute for DRM'ing content to prevent unauthorised playout."
> 
> 	Today in MPEG, people are also working on methods to enable playback
> control of DASH clients. Needless to say that the non-normative nature of
> DASH client behaviors makes difficult to enforce such a control from the
> client side. However, one way to control what a DASH client may or may not
> playback is to control the delivery of the segments in the first the place.
> Hence being sure that a specific content is not going to be played out. And
> this decision can be motivated by business rules or any other context. So
> using DRM for that purpose wouldn't be appropriate because the client has
> the right to watch the content (e.g. he paid for it) but he just needs to
> perform certain actions first in order to retrieve the content (e.g.
> retrieve an ad).
> 
> Regards,
> Emmanuel
> 
> Having a path_pattern attribute to allow a uCDN/Content Provider to have a
> token match multiple URLs is sensible and something that's used by CDNs
> today. That solves the segmented content case I believe.
> 
> The chained tokens I don't see how they add material benefit over a token
> with a long expiry time. If someone can share a manifest, they can share a
> URL for a video segment. Tokens were originally used to avoid people being
> able to download large files they couldn't play or install, etc. that the
> content provider had to pay for. They're not a substitute for DRM'ing
> content to prevent unauthorised playout.
> 
> Ben
> 
> 
> 
> > The current URI Signing draft already includes support for both symmetric
> hashes as well as asymmetric encryption of tokens/URIs. If the tokens were
> not hashed/encrypted, a UA would be free to adjust the expiration time in
> them, thereby negating the use of any signature in the first place.
> >
> > The main issue solved by the chained tokens concept is not so much how the
> token is encrypted, but how to make sure that I can give my manifest/MPD to
> an illegitimate client and he can fetch content from the CDN. By having a
> chain of tokens, each with a short expiration time, you reduce this
> vulnerability in the same way that existing URI Signing does this for
> regular (non-segmented) content.
> >
> > Best regards,
> >
> > Ray
> >
> >
> >
> >
> >
> >> Ray talked about chained signed tokens and I wondered if using
> asymmetrically encrypted tokens would solve the use case?
> >>
> >> All dCDNs could decrypt the token contents (they are in the clear today)
> using public keys but only the generator of the token could create a token
> and there are no issues of sharing shared secrets between CDNs?
> >>
> > This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you are
> requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use it
> and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 26 Mar 2015 17:40:33 +0000

Hi Ray/Ben,

  I agree that the having a path_pattern attribute makes sense.

  Wrt the chained tokens, from the slides it looked like this was just to allow the dCDN to create new tokens for content that was not explicitly delegated by the uCDN (e.g., where the client is just generating URLs using a template).  Is that correct?

  In that case, the uCDN needs to be able to delegate the class of URLs that the dCDN may resign?  And the proposal is that the path_pattern be in the original signed URL from the uCDN, which implicitly delegates that set of pattern matched URLs to the dCDN?  Is that correct?

  And at that point, the dCDN can use any keys that it wants (i.e., they don't have to be interoperable with the CSP or uCDN)?  Is that also correct?

  If so, then chained tokens are not actually interconnection related?  The delegation of the signing from uCDN to dCDN is an interconnection issue, but the actual subsequent signing by the dCDN is an internal function (including specifying the token header and client handling of that header)?  Is that correct?

thanx!

--  Kevin J. Ma

From: CDNi [mailto:[email-masked]] On Behalf Of Brandenburg, R. (Ray) van
Sent: Thursday, March 26, 2015 7:07 AM
To: Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [CDNi] MPEG & Chained tokens

Hi Ben,

Completely agree.

Ray

Ben

Hi Ben,

Best regards,

Ray

Ben

---

From: "Thomas, E.D.R. (Emmanuel)" <[email-masked]>
Date: Thu, 26 Mar 2015 18:00:17 +0000

Hi Kevin,

	Sorry for not being clear enough. I fully agree that DRM and access token solve orthogonal problems, respectively playout control and unnecessary delivery costs. And these technical measures can be perfectly used in combination with each other since they solve orthogonal problems. No debate.

	In fact, I was merely reporting the ongoing discussion taking place in MPEG DASH about playback control, ie how to recommend a client to download segments in a specific order. From your comment I understand that it seems to be out-of-scope of this discussion, so let's leave it here.

Regards,
Emmanuel

-----Original Message-----
From: Kevin Ma J [mailto:[email-masked]] 
Sent: donderdag 26 maart 2015 18:32
To: Thomas, E.D.R. (Emmanuel); Ben Niven-Jenkins; Brandenburg, R. (Ray) van
Cc: [email-masked]
Subject: RE: [CDNi] MPEG & Chained tokens

Hi Emmanuel,

thanx.

--  Kevin J. Ma

> coordinating the effort from MPEG concerning the use of URI Signing, 
> and its possible improvements, in MPEG DASH.
> 
> control of DASH clients. Needless to say that the non-normative nature 
> of DASH client behaviors makes difficult to enforce such a control 
> from the client side. However, one way to control what a DASH client 
> may or may not playback is to control the delivery of the segments in the first the place.
> Hence being sure that a specific content is not going to be played 
> out. And this decision can be motivated by business rules or any other 
> context. So using DRM for that purpose wouldn't be appropriate because 
> the client has the right to watch the content (e.g. he paid for it) 
> but he just needs to perform certain actions first in order to retrieve the content (e.g.
> retrieve an ad).
> 
> Regards,
> Emmanuel
> 
> Having a path_pattern attribute to allow a uCDN/Content Provider to 
> have a token match multiple URLs is sensible and something that's used 
> by CDNs today. That solves the segmented content case I believe.
> 
> The chained tokens I don't see how they add material benefit over a 
> token with a long expiry time. If someone can share a manifest, they 
> can share a URL for a video segment. Tokens were originally used to 
> substitute for DRM'ing content to prevent unauthorised playout.
> 
> Ben
> 
> 
> 
> hashes as well as asymmetric encryption of tokens/URIs. If the tokens 
> were not hashed/encrypted, a UA would be free to adjust the expiration 
> time in them, thereby negating the use of any signature in the first place.
> >
> token is encrypted, but how to make sure that I can give my 
> manifest/MPD to an illegitimate client and he can fetch content from 
> the CDN. By having a chain of tokens, each with a short expiration 
> time, you reduce this vulnerability in the same way that existing URI 
> Signing does this for regular (non-segmented) content.
> >
> > Best regards,
> >
> > Ray
> >
> >
> >
> >
> >
> using public keys but only the generator of the token could create a 
> token and there are no issues of sharing shared secrets between CDNs?
> >>
> are not the addressee or if this message was sent to you by mistake, 
> you are requested to inform the sender and delete the message. TNO 
> accepts no liability for the content of this e-mail, for the manner in 
> which you use it and for damage of any kind resulting from the risks 
> inherent to the electronic transmission of messages.
>

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 26 Mar 2015 21:54:16 +0000

Hi Kevin,

Since the client will typically, after retrieving the MPD, request segments directly from the dCDN (either by generation of URLs via a template or via relative URLs), these are not explicitly delegated to the dCDN and hence there is no redirection involved. In addition to the use of chained tokens that you mention, a second use is that it allows a relatively short expiration time, thereby reducing the risk of deep-linking.

Note that it is possible for a manifest to be delivered by a CSP or uCDN and for the segment to be delivered by a dCDN.

Yes, that is correct. In order to start up the chain, both the CSP and uCDN need to understand the chained tokens algorithm in order to create the initial token (which includes setting the initial path_pattern and time_increment values which depend on the content). An advantage of this is that CDNs can be both fully stateless as well as DASH un-aware.

That depends on the exact case. In the case where everything (including the manifest) is delivered from the dCDN, you’re right. In other cases, it is important that keys used are shared.

See my comments above, it depends on how the distribution of manifest and segments is delegated. The only way the integrity of the chain is maintained if it is continued from the entire path from CSP->uCDN->dCDN.

Also note that the current URI Signing spec explicitly includes the use case where it is used in non-CDNI use cases (see section 1.4). As Francois mentioned during the meeting, the first implementations based on the current draft specification are already used in CDNs, and in those cases it is used on the CSP->CDN interface (e.g. single CDN).

Thanks,

Ray

thanx!

--  Kevin J. Ma

From: CDNi [mailto:[email-masked]] On Behalf Of Brandenburg, R. (Ray) van
Sent: Thursday, March 26, 2015 7:07 AM
To: Ben Niven-Jenkins
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] MPEG & Chained tokens

Hi Ben,

Completely agree.

Ray

Ben

Hi Ben,

Best regards,

Ray

Ben

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 26 Mar 2015 23:49:18 +0000

Hi Ray,

> That depends on the exact case. In the case where everything (including the manifest) is delivered from the dCDN, you’re right. In other cases, it is important that keys used are shared.

  On this one, I was only referring to the chained token, not the original token.  The dCDN would need the shared/public keys for the initial delegation (on redirect of either manifest or segment from CSP/uCDN), but all the subsequent tokens generated for subsequent segment requests (or even manifest requests, depending on what the path_pattern is) could use any key/method the dCDN wanted, until it wishes to further delegate?

  For CDNI, an alternative to standardizing an HTTP header (for returning the token) would be to designate a metadata field to distribute the HTTP header name.  From the CDNI point of view, the important thing is that all the CDNs use the same HTTP header, e.g., if it's a non-standard client?

thanx.

--  Kevin J. Ma

From: Brandenburg, R. (Ray) van [mailto:[email-masked]] 
Sent: Thursday, March 26, 2015 5:54 PM
To: Kevin Ma J; Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [CDNi] MPEG & Chained tokens

Hi Kevin,

 

 

Thanks,

Ray

thanx!
 
--  Kevin J. Ma

Hi Ben,

 

Completely agree.
 
Ray

On 25 Mar 2015, at 17:58, Ben Niven-Jenkins <[email-masked]> wrote:
Ray,

Ben

Hi Ben,

 
Best regards,
 
Ray

 

 
Ben

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Fri, 27 Mar 2015 00:06:04 +0000

Hi Kevin,

Thanks for your comments. 

>  On this one, I was only referring to the chained token, not the original token.  The dCDN would need the shared/public keys for the initial delegation (on redirect of either manifest or segment fr…

In most cases, yes. However, there are some corner cases where that might not work. For example, let’s say you have a situation where the manifest lists one representation as coming from the uCDN (with a URI template), and the other from the dCDN (with another URI template). Or alternatively, the manifest (updates) coming from the uCDN with the segments coming from the dCDN. In those cases you want to make sure that you don’t need to maintain two token chains. In other words, a token generated by the dCDN might be needed for a later request in the uCDN. You don’t know beforehand which segment will be requested next. 

I’m not saying the examples above are valid in all cases, but the way I see it, we should see the information elements in the draft as a toolbox that CSPs can use to choose a combination that suits their purpose. Some CDNs will only use Expiration Time for enforcement, some will add Client IP, others will add path_pattern. Some will use the chained token mechanism across different CDNs, other within a single CDN, and others won’t use it at all.

>  For CDNI, an alternative to standardizing an HTTP header (for returning the token) would be to designate a metadata field to distribute the HTTP header name.  From the CDNI point of view, the impo…

That’s a good point. We don’t necessarily need to standardize the HTTP header. The current draft does something similar for the URI Signing package attribute: the name of the package attribute is communicated through the CDNI Metadata interface or via configuration. If it is not communicated or configured, it defaults to ‘URISigningPackage’. We could do something similar here. 

If we choose to go for this route, we do need to make sure that MPEG adds a field for communicating the name of this header to the MPD. The client will need it to know which header to echo back in the next request. 

Thanks,

Ray