RE: Security evaluation of an example DAP policy

Hi Richard,

I just comment on the non-legal part.
The numbering schemes are the headache of the telco industry and I assume W3C will not help too much, but who knows.

>>> >>The weather.example.com Widget can connect to weather.example.com
>>> >>without notifying the user, except when roaming.
>>How do we cover the additional 113 million+ domain names (and x number
>>of subdomains) on the web via a policy such as this? Is that a blanket
>>'deny all' and a fall back to user prompting for those 113 million web
>>sites not explictly included in a policy document? Most importantly from
>>the previous questions, does domain-based policy then work in the web
>>context? If a policy covers 10,000 domains (or, let's say, 1 million
>>domains) is the ability to reach 1% of web content enough incentive to
>>provide a web policy?
This case is about widgets, therefore WARP-like + DigSig model works. Additionally BONDI adds the following subject attributes:
install-uri
id
version
distributor-key-cn
distributor-key -fingerprint
distributor-key-root-cn
distributor-key-root-fingerprint
author-key-cn
author-key -fingerprint
author-key-root-cn
author-key-root-fingerprint
widget-attr:name

If we would extend the problem to websites, then I think that the solution is already in place in the Web and in BONDI.
It is based on X.500, X.509, root certificates and the tree-(or graph-?)structured trust model.
Specifically in BONDI A&S we have  subject attributes like "key-root-cn" and "sign-schema".
'sign-schema="tls"' says:
"The page was fetched using HTTPS and the browser has verified that the site certificate’s Common Name matches the host that the page was fetched from, and it has already applied its own policies regarding whether the root certificate is in an acceptable trust domain."

The pages served over plain http could be blocked from accessing DAPI.

Thanks,
Marcin

________________________________________
From: richard.tibbett@orange-ftgroup.com [richard.tibbett@orange-ftgroup.com]
Sent: Friday, November 20, 2009 7:30 PM
To: Marcin Hanclik; Frederick.Hirsch@nokia.com; jorlow@chromium.org
Cc: mjs@apple.com; jonas@sicking.cc; w3c@adambarth.com; robin@berjon.com; public-device-apis@w3.org; public-webapps@w3.org
Subject: RE: Security evaluation of an example DAP policy

Hi,

> >>The weather.example.com Widget can connect to weather.example.com
> >>without notifying the user, except when roaming.

How do we cover the additional 113 million+ domain names (and x number
of subdomains) on the web via a policy such as this? Is that a blanket
'deny all' and a fall back to user prompting for those 113 million web
sites not explictly included in a policy document? Most importantly from
the previous questions, does domain-based policy then work in the web
context? If a policy covers 10,000 domains (or, let's say, 1 million
domains) is the ability to reach 1% of web content enough incentive to
provide a web policy?

> >>Reliably identified Websites can send and receive SMS except to
> >>premium rate numbers.

If policy is interchangeable, and we have e.g. 100 policy providers, how
does the developer have confidence that each policy provider has
selected the same set of premium phone numbers to block? Can such a
policy be intentionally extended to prohibit non-threatening use cases
at the expense of the user? If this is such an integral security issue,
it should be possible to bake it in to the API itself? If it is not
possible to bake it in, and the security decision is subjective based on
whoever is providing a policy, then is this something web developers
will be able to reliably and consistently code against?

What is the legal responsibility (for data loss / misuse / corruption /
etc) that policy providers take on by 'guaranteeing the web'? Is a
policy provider liable for actions that it decides on behalf of a user?
Over e.g. 1 million web domains?


I appreciate the input of solid use cases such as this for discussion.

I look forward to a use case that shows a clear reason for policy in a
web context considering the massively distributed and centrally
unmanageable nature of the web world - one of the tenants of its design
that arguably continues to make it so successful.

Kind Regards,

Richard

> -----Original Message-----
> From: public-device-apis-request@w3.org
> [mailto:public-device-apis-request@w3.org] On Behalf Of Marcin Hanclik
> Sent: 20 November 2009 15:13
> To: Frederick Hirsch; ext Jeremy Orlow
> Cc: Maciej Stachowiak; Jonas Sicking; Adam Barth; Robin
> Berjon; public-device-apis@w3.org; public-webapps WG
> Subject: RE: Security evaluation of an example DAP policy
>
> Hi,
>
> >>Reliably identified Websites can send and receive SMS except to
> >>premium rate numbers.
> There seems to be no worldwide pattern to recognize the
> premium numbers based on the number itself, this could be
> some network operators service or something similar
> IP-geolocation databases. The policy would be very looooong
> if we would put all the worldwide available premium numbers into it.
> Therefore this use case is not fully doable out of the box.
> However, BONDI allows to (reliably?) identify websites and
> allows to control sending and receiving SMS.
>
> >>The weather.example.com Widget can connect to weather.example.com
> >>without notifying the user, except when roaming.
> I am not sure what " weather.example.com Widget".
> I assume it is the widget that was downloaded from
> weather.example.com.
> The BONDI policy format would encode this e.g. like this:
>
> <policy-set combine="deny-overrides">
>  <policy description="">
>   <target>
>    <subject>
>      <subject-match attr="class" match="website" func="equal"/>
>      <subject-match attr="uri.host"
> match="weather.example.com" func="equal"/>
>    </subject>
>    <subject>
>      <subject-match attr="class" match="widget" func="equal"/>
>      <subject-match attr="install-uri.host"
> match="weather.example.com" func="equal"/>
>    </subject>  </target>
>   <rule effect="deny">
>    <condition combine="or">
>      <environment-match attr="roaming"
> func="equal">international</resource-match>
>    </condition>
>   </rule>
>   <rule effect="permit"> //this seems not needed
>    <condition combine="or">
>      <environment-match attr="roaming"
> func="equal">national</resource-match>
>    </condition>
>   </rule> </policy>
> </policy-set>
>
> Thanks,
> Marcin
>
> P.S. I think I will not write more policies until there is
> some use case that is not doable (at least in my opinion. I
> may be wrong.)
>
> Marcin Hanclik
> ACCESS Systems Germany GmbH
> Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
> Mobile: +49-163-8290-646
> E-Mail: marcin.hanclik@access-company.com
>
> -----Original Message-----
> From: Frederick Hirsch [mailto:Frederick.Hirsch@nokia.com]
> Sent: Friday, November 20, 2009 3:29 PM
> To: ext Jeremy Orlow
> Cc: Frederick Hirsch; Marcin Hanclik; Maciej Stachowiak;
> Jonas Sicking; Adam Barth; Robin Berjon;
> public-device-apis@w3.org; public-webapps WG
> Subject: Re: Security evaluation of an example DAP policy
>
> Jeremy
>
> Thanks. I want to make sure I understand the concerns.
>
> I guess the question is whether one can bake all the security
> in that is needed for various (possibly conflicting) use
> cases, including those that do not presume user interaction.
> An argument for  policy is to decouple the mechanism from the
> decision criteria to get that flexibility, while making sure
> the mechanism is secure.  On the other side I hear the
> concern that the mechanism cannot be as secure.
>
> I note that the policy requirements document includes some
> use cases Paddy contributed in an earlier email:
>
> http://dev.w3.org/2009/dap/policy-reqs/#use-cases
>
> So for example, how does one "bake in" these:
>
> The weather.example.com Widget can connect to
> weather.example.com without notifying the user, except when roaming.
>
> Reliably identified Websites can send and receive SMS except
> to premium rate numbers.
>
> Do we need to go into more detail on these two (as examples)?
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Nov 20, 2009, at 9:15 AM, ext Jeremy Orlow wrote:
>
> > These are reasons, but I think the greatest cause of our concern is
> > that we have not seen any examples of how policies can provide the
> > same level of security that baking security into the API from the
> > beginning can provide.
> >
> > All too often the policy based approaches fall back on
> either asking
> > the user or simply denying access--both of which are not viable
> > solutions in most cases within the browser.  If we take
> security into
> > account when designing the APIs we can often find creative
> approaches
> > that satisfy all of the requirements/use-cases while
> providing an API
> > that can be on by default.
> >
> > On Fri, Nov 20, 2009 at 1:53 PM, Frederick Hirsch
> > <frederick.hirsch@nokia.com
> > > wrote:
> > My understanding from reading the thread is that the
> concern is with
> > complexity, increased attack surface due to mechanisms that can be
> > used in unanticipated ways or misconfigured, and management issues.
> >
> > Thus though policy can state a simple approach, I'm not
> sure the above
> > concerns are addressed by that expression.
> >
> > I think we need to work through the use cases, both for
> those that do
> > need a policy language and those that do not, then consider if APIs
> > have various methods as Robin suggested, or otherwise how
> it will all
> > fit together.
> >
> > regards, Frederick (not as chair)
> >
> > Frederick Hirsch
> > Nokia
> >
> >
> >
> >
> > On Nov 19, 2009, at 7:49 PM, ext Marcin Hanclik wrote:
> >
> > Hi Jonas, Maciej,
> >
> > It seems that the policy that you would accept would be:
> >
> > <policy-set combine="deny-overrides">
> > <policy description="Default Policy for websites. Simply
> denying all
> > API that are covered by some device capability:) ">  <target>
> >    <subject>
> >      <subject-match attr="class" match="website" func="equal"/>
> >    </subject>
> >  </target>
> >  <rule effect="deny">
> >    <condition>
> >      <resource-match attr="device-cap" func="regexp">/.+/</resource-
> > match>
> >    </condition>
> >  </rule>
> > </policy>
> > </policy-set>
> >
> > Let's see how DAP will evolve then.
> >
> > Thanks,
> > Marcin
> > ________________________________________
> > From: Maciej Stachowiak [mjs@apple.com]
> > Sent: Friday, November 20, 2009 1:26 AM
> > To: Jonas Sicking
> > Cc: Marcin Hanclik; Adam Barth; Robin Berjon;
> > public-device-apis@w3.org ; public-webapps WG
> > Subject: Re: Security evaluation of an example DAP policy
> >
> > On Nov 19, 2009, at 4:23 PM, Jonas Sicking wrote:
> >
> > On Thu, Nov 19, 2009 at 4:07 PM, Marcin Hanclik
> > <Marcin.Hanclik@access-company.com> wrote:
> > Hi Adam,
> >
> > I think that
> > <resource-match attr="param:name" func="regexp">/(C|c):\\(.+)\\(.+)/
> > <resource-match />
> > should be
> > <resource-match attr="param:name" func="regexp">/(C|c):\\([^\\]+)\\.
> > +/<resource-match />
> > up to any further bug in the RE.
> > Sorry, my problem.
> >
> > Anyway, the general comment is that the use case is under control
> > based on the current spec.
> >
> > For what it's worth, I think any API that opened a dialog
> asking the
> > user "Do you want to give website X access to directory Y
> in your file
> > system" would not be an API we'd be willing to implement in firefox.
> > I.e. our security policy would be to always deny such a
> request (thus
> > making implementing the API useless for our users).
> >
> > Ditto for Safari.
> >
> >  - Maciej
> >
> >
> > ________________________________________
> >
> > Access Systems Germany GmbH
> > Essener Strasse 5  |  D-46047 Oberhausen HRB 13548 Amtsgericht
> > Duisburg
> > Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
> >
> > www.access-company.com
> >
> > CONFIDENTIALITY NOTICE
> > This e-mail and any attachments hereto may contain
> information that is
> > privileged or confidential, and is intended for use only by the
> > individual or entity to which it is addressed. Any
> disclosure, copying
> > or distribution of the information by anyone else is strictly
> > prohibited.
> > If you have received this document in error, please notify
> us promptly
> > by responding to this e-mail. Thank you.
> >
> >
> >
> >
>
>
> ________________________________________
>
> Access Systems Germany GmbH
> Essener Strasse 5  |  D-46047 Oberhausen HRB 13548
> Amtsgericht Duisburg
> Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
>
> www.access-company.com
>
> CONFIDENTIALITY NOTICE
> This e-mail and any attachments hereto may contain
> information that is privileged or confidential, and is
> intended for use only by the individual or entity to which it
> is addressed. Any disclosure, copying or distribution of the
> information by anyone else is strictly prohibited.
> If you have received this document in error, please notify us
> promptly by responding to this e-mail. Thank you.
>
>

________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Friday, 20 November 2009 20:49:36 UTC