Re: FW: VoiceXML 2.1 and PI issue

CC'ing www-voice@xxxxxx

Dave Raggett wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Brad,

I remain nervous about the effectiveness of the model you describe,
since as far as I can tell, the document author could put whatever
IP addresses he wants to access into the PI, and the browser would
happily oblige. 

The provider of the XML data can put whatever IP or domain he wishes into the PI.  The author of the VoiceXML document requesting that XML data can not put whatever IP address he wants when serving his content, nor can the author of the VoiceXML document state which XML data he has access to. 

I would be much happier with a simple sandbagging
policy enforced by the browser that the author can't screw up. In
other words, relying on the browser to limit the <data/> element to
the same server or domain that the document was downloaded from. 

The VoiceXML 2.1 specification allows platform vendors to use this security model instead if they prefer in the event that a PI is not included.  The security model you propose is quite appropriate for that case, but does not allow a provider of particular XML data (say weather, movie, or package tracking information) to make it available to another VoiceXML site and therefore it does not afford some of the flexibility that is required.

If
a more flexible policy is needed it could be arranged with the sys
admins responsible for the VoiceXML interpreter. 

Our model of VoiceXML browser is the same as the web model for HTML.  The browser may be distributed and you may wish to make your VoiceXML content available to multiple browsers (for instance, an extreme example is that at some point you may have you own personal VoiceXML browser of choice running on your cell phone fetching voice content over the data channel).  Coordinated configuration between the web server and the web browser is something we want to architecturally avoid.  This property of HTML has greatly increased its adoption. 

In this view there
is no need for a PI or equivalent means for authors to set their own
policy, as the security policy should be handled out of band, just
like who can update what areas of a website on an HTTP server.
Perhaps I am misunderstanding something?
  

Transparency of security policy is a good principle and as described above it is perfectly reasonable if the PI is not included to use domain checks.  The PI allows XML data providers the ability to specify "access rights" to their content.  We find this policy greatly expands the willingness and ease of sharing data between XML data providers. 

I am interested to see what comments Dan Connolly may have on this,
and am very happy to take part in a phone call once we have answered
some of the open questions on this issue.
  

Yes, I am very interested also!

Brad

Regards,

- -- Dave Raggett

On Tue, 12 Oct 2004, Brad Porter wrote:

  

We have performed security analysis of this solution.  The sandboxing 
restriction is to prevent "file open" to sensitive XML content.  
Sandboxing solutions require that the browser enforce the sandbox.

The sandboxing we're enforcing here is that application author is not 
trusted to access any XML content that the browser has access to.  This 
is the same as an applet developer not being trusted with file open to 
the contents of your local filesystem or with general network socket or 
HTTP access to your local intranet.  Also the same as a _javascript_ page 
not having access to the data in another frame. 

The security policy is not designed to authenticate the provider of the 
data and you are correct that the PI does not provide any value there.  
As you state, digital certificates should be used in that instance. 

The security policy is similarly not designed to prevent proxies or 
network trace elements from viewing the content.  HTTPS should be used 
in that instance.

The PI is designed to provide enough information to the browser to 
determine whether access to that XML resource by the application is 
allowed or not. 

If this seems incorrect or confusing, I am happy to describe in person 
and would certainly appreciate further security review. 

Brad

Dave Raggett wrote:

    

Hi Brad,

Do you have a security analysis of the PI solution? 

- From a quick glance, if the <data/> element is used with a static
URI, the PI doesn't offer any additional security, since both the
data element and the PI can be generated by a hostile party.
Assuming the document was created by a friendly party, then the PI
could provide a safeguard against a broken script when the <data/>
element is used with a dynamically generated URI (srcexpr). That
small benefit could also be conferred through the use of attributes
(e.g. on the <data/> element) in place of the PI.

A simpler and safer option is for the browser to limit <data/> to
the same server or perhaps the same domain as was used to retrieve
then VoiceXML 2.1 document it is contained within. If the document
author isn't to be trusted, and we want to allow <data/> to be used
with other servers/domains, then a more secure way of passing
information to the browser seems to be needed, for instance,
digitally signed by a trusted third party.

How many companies have implemented the PI solution as defined in
Appendix E?

Regards,

-- Dave Raggett
      

 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBbBW6b3AdEmxAsUsRAvwuAJ4tXmODxRWY5YkztTtSGavu2k/ANwCdHyOl
5DpTSKg7w/2nUvhVb6a6RVw=
=5F9c
-----END PGP SIGNATURE-----