Re: FW: VoiceXML 2.1 and PI issue

CC'ing www-voice@w3.org

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-----
>
>  
>