(In reply to Joe Steele from comment #0)
> The usage of destinationURL has been removed from section 8.2. "Selecting a
> Supported Key System and Using Initialization Data from the 'needkey'
> Event". This should be added back in to let application implementors know
> that it is required for some CDMs.

I don't think destinationURL was ever in the examples.

As discussed in the telecon, your use case is unclear. The "needkey" event interface [1] has never had a URL. destinationURL has always only been in the "message" event interface [2].

The Queue a "message" Event algorithm [3] defines the creation of [2]. It may be called in four cases:
 1) createSession() algorithm (destinationURL is null)
 2) loadSession() algorithm
 3) update() algorithm
 4) Other times the CDM needs to send a message, such as to request renewal.

The example in 8.2 is a simple one that assumes the "message" event is a license request, which it handles in licenseRequestReady(). This is case #1.

[1] https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#dom-mediakeyneededevent
[2] https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#dom-mediakeymessageevent
[3] https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#algorithms-queue-message

In example 8.2 'Selecting a Supported Key System and Using Initialization Data from the "encrypted" Event', the code assumes that license URL can be preset by the application, which the example does in the selectKeySystem() function. I would like the example to remove all references to the global var licenseUrl and instead use the URL that is returned in the message. Here is the example code for the licenseRequestReady() function I would like to see instead. 

function licenseRequestReady(event) {
    var request = event.message;
    var licenseUrl = event.destinationURL;  // <== THIS IS THE NEW BIT
    var xmlhttp = new XMLHttpRequest();
    xmlhttp.keySession = event.target;
    xmlhttp.open("POST", licenseUrl);
    xmlhttp.onreadystatechange = function() {
      if (xmlhttp.readyState == 4) {
        var license = new Uint8Array(xmlhttp.response);
        xmlhttp.keySession.update(license).catch(
          console.error.bind(console, "update() failed")
        );
      }
    }
    xmlhttp.send(request);
}

Examples 8.3, 8.4 and 8.5 make a similar assumption about where licenseUrl is coming from.

Example 8.2 expects a single message per session^. As I noted in comment #1, this is case #1 and the message is generated by createSession(). Thus, event.destinationURL is NULL.

^ This example is not robust and would likely fail in some real world scenarios. We could consider making the examples more robust, but the goal is to explain usage of the APIs without being overly complex. Maybe a simple comment that a real application should handle multiple messages would be sufficient.

(In reply to David Dorwin from comment #3)
> Example 8.2 expects a single message per session^. As I noted in comment #1,
> this is case #1 and the message is generated by createSession(). Thus,
> event.destinationURL is NULL.

Ah -- I misread what you were saying. In that case I am objecting to that section of the createSession() algorithm (7.8). *Any* request sent by the CDM must have the opportunity to supply the URL to be used. 

> 
> ^ This example is not robust and would likely fail in some real world
> scenarios. We could consider making the examples more robust, but the goal
> is to explain usage of the APIs without being overly complex. Maybe a simple
> comment that a real application should handle multiple messages would be
> sufficient.

This example will fail in general for any CDM which requires a per-origin initialization involving server communication.

(In reply to Joe Steele from comment #4)
> (In reply to David Dorwin from comment #3)
> > Example 8.2 expects a single message per session^. As I noted in comment #1,
> > this is case #1 and the message is generated by createSession(). Thus,
> > event.destinationURL is NULL.
> 
> Ah -- I misread what you were saying. In that case I am objecting to that
> section of the createSession() algorithm (7.8). *Any* request sent by the
> CDM must have the opportunity to supply the URL to be used. 

Where would the URL come from?
> 
> > 
> > ^ This example is not robust and would likely fail in some real world
> > scenarios. We could consider making the examples more robust, but the goal
> > is to explain usage of the APIs without being overly complex. Maybe a simple
> > comment that a real application should handle multiple messages would be
> > sufficient.
> 
> This example will fail in general for any CDM which requires a per-origin
> initialization involving server communication.

Can you give an example where such initialization would fail? Why wouldn't the server specified by licenseUrl for the key system be able to handle the initialization? What server would be specified in destinationURL?

(In reply to David Dorwin from comment #5)
> (In reply to Joe Steele from comment #4)
> > (In reply to David Dorwin from comment #3)
> > > Example 8.2 expects a single message per session^. As I noted in comment #1,
> > > this is case #1 and the message is generated by createSession(). Thus,
> > > event.destinationURL is NULL.
> > 
> > Ah -- I misread what you were saying. In that case I am objecting to that
> > section of the createSession() algorithm (7.8). *Any* request sent by the
> > CDM must have the opportunity to supply the URL to be used. 
> 
> Where would the URL come from?

The CDM would provide the URL and it would base it on either the initData or other information in the CDM itself, either hard-coded or provided at install time. 

> > 
> > > 
> > > ^ This example is not robust and would likely fail in some real world
> > > scenarios. We could consider making the examples more robust, but the goal
> > > is to explain usage of the APIs without being overly complex. Maybe a simple
> > > comment that a real application should handle multiple messages would be
> > > sufficient.
> > 
> > This example will fail in general for any CDM which requires a per-origin
> > initialization involving server communication.
> 
> Can you give an example where such initialization would fail? Why wouldn't
> the server specified by licenseUrl for the key system be able to handle the
> initialization? What server would be specified in destinationURL?

The licenseURL and the initialization URL may have no relationship. For example in the Adobe Access case, the initialization URL is a central Adobe server and the license servers may be Adobe servers or may be customer on-premise servers.

(In reply to Joe Steele from comment #6)
> The CDM would provide the URL and it would base it on either the initData or
> other information in the CDM itself, either hard-coded or provided at
> install time. 

It can't be based on the initData (see bug 25920). If it's hard-coded, that wouldn't be per-origin or really need to go through the EME APIs.

> The licenseURL and the initialization URL may have no relationship. For
> example in the Adobe Access case, the initialization URL is a central Adobe
> server and the license servers may be Adobe servers or may be customer
> on-premise servers.

How can it be a central server or a customer server? How would the CDM know which to pick?

(In reply to David Dorwin from comment #7)
> (In reply to Joe Steele from comment #6)
> > The CDM would provide the URL and it would base it on either the initData or
> > other information in the CDM itself, either hard-coded or provided at
> > install time. 
> 
> It can't be based on the initData (see bug 25920). If it's hard-coded, that
> wouldn't be per-origin or really need to go through the EME APIs.

I dismissed the argument in bug 25920 when it was made. The initData can and does contain URL information for some DRM systems. Also, having the URL be hard-coded does not dismiss the per-origin requirement. I did not say that the URL was per-origin, merely that the initialization was. In our case this resulted directly from the requirements in the security section for restricting the amount of shareable information. 

> 
> > The licenseURL and the initialization URL may have no relationship. For
> > example in the Adobe Access case, the initialization URL is a central Adobe
> > server and the license servers may be Adobe servers or may be customer
> > on-premise servers.
> 
> How can it be a central server or a customer server? How would the CDM know
> which to pick?

If the URL is coming from the initData, the customer who packaged the content was able to define the URL. The license server that the URL points to may be run by the CDM provider or may be run by the content provider. I can also imagine there being policy in the initData to allow the CDM to choose from a list of URLs provided in the policy, based on the CDM instance (for example CDM instance 4 of 10 might use a different URL)  for load balancing.

To re-iterate what I said on the call: I see legitimate use-cases for the CDM to supply routing information along with the message. If we don't provide an explicit field for this CDMs will just redefine their message format to be a ( routing, message ) pair.

I don't see how we could ban CDMs from basing this routing information in part on information in the initData.

The question of the security of the initData is a general one. Keysystem designs need to consider the security implications of using this information. Obviously, the security considerations for information that might influence message routing is different from that for information which might only influence message contents, since you could cause the message not to be sent to the expected place. That is, an attack on the message contents could be mitigated at the server, but an attack on the message routing cannot, because the server might never see the message.

Perhaps we need some information in the security considerations about the need to protect initData ?

As far as this bug goes, we should avoid showing an example with a security hole, so perhaps the example should mention that the CDM needs to have validated the URL or even show the page validating the URL ?

(In reply to Mark Watson from comment #9)
> To re-iterate what I said on the call: I see legitimate use-cases for the
> CDM to supply routing information along with the message. If we don't
> provide an explicit field for this CDMs will just redefine their message
> format to be a ( routing, message ) pair.
> 
> I don't see how we could ban CDMs from basing this routing information in
> part on information in the initData.

Agreed. We would definitely do this for our CDM.  

> 
> The question of the security of the initData is a general one. Keysystem
> designs need to consider the security implications of using this
> information. Obviously, the security considerations for information that
> might influence message routing is different from that for information which
> might only influence message contents, since you could cause the message not
> to be sent to the expected place. That is, an attack on the message contents
> could be mitigated at the server, but an attack on the message routing
> cannot, because the server might never see the message.
> 
> Perhaps we need some information in the security considerations about the
> need to protect initData ?

This is a good idea. However we already have some text in section 7.1.3 Tracking to address this (see "Encryption of user identifiers"). Maybe we should expand that text to specifically discuss when identifiers are sent as part of a key request message?

> 
> As far as this bug goes, we should avoid showing an example with a security
> hole, so perhaps the example should mention that the CDM needs to have
> validated the URL or even show the page validating the URL ?

That makes some sense. Validation of the domain and protocol being sent to should be possible for all DRM systems I am aware of. 

One thing I failed to mention in the meeting today - the list of possible URLs for the key request to be sent to should be known by the application. The specific concern I have is that there may be a list of valid URLs and the application does not know apriori which one the message is intended for. In this case the application could just validate against a list of known domains and protocols.

(In reply to Joe Steele from comment #10)
> (In reply to Mark Watson from comment #9)
> > Perhaps we need some information in the security considerations about the
> > need to protect initData ?
> 
> This is a good idea. However we already have some text in section 7.1.3
> Tracking to address this (see "Encryption of user identifiers"). Maybe we
> should expand that text to specifically discuss when identifiers are sent as
> part of a key request message?
> 

The attack is that the message is routed to the wrong place, which is a security issues. One of the things an attacker could do once they've achieved this might be to abuse identifiers in the messages, which would be a privacy issue.

We should address the underlying security issue (mis-routing of messages) - it would still be an issue even if the identifiers were not present.

(In reply to Mark Watson from comment #11)
> (In reply to Joe Steele from comment #10)
> > (In reply to Mark Watson from comment #9)
> > > Perhaps we need some information in the security considerations about the
> > > need to protect initData ?
> > 
> > This is a good idea. However we already have some text in section 7.1.3
> > Tracking to address this (see "Encryption of user identifiers"). Maybe we
> > should expand that text to specifically discuss when identifiers are sent as
> > part of a key request message?
> > 
> 
> The attack is that the message is routed to the wrong place, which is a
> security issues. One of the things an attacker could do once they've
> achieved this might be to abuse identifiers in the messages, which would be
> a privacy issue.
> 
> We should address the underlying security issue (mis-routing of messages) -
> it would still be an issue even if the identifiers were not present.

I agree that we should address the potential mis-routing issue. However, it really should not matter whether the messages are routed correctly or not. My suggestion would be to add some text that requires encryption whenever identifiers are included in messages. Maybe even require that the keys used only be known to the targeted server(s) although that may be hard to spec well. If this recommendation was followed, it would make abusing identifiers much harder.  A MiTM should not be able to derive any useful information from the key request without owning the keys.

This was part of the point I was trying to make in bug 26332. If an attacker can send you to an alternate URL, there is no reason they can't send you to an alternate *secure* URL (secure in the sense that the browser will accept the server certificate). So the message still needs to be encrypted within that SSL/TLS channel to ensure privacy for the user.

The concerns expressed in this bug go beyond the examples, which never included "destinationURL", and have been discussed in several other bugs. As discussed in the telecon yesterday, we will continue discussion in bug 26683.

*** This bug has been marked as a duplicate of bug 25920 ***