Re: Security use cases for packaging

2015-01-30 Thread Daniel Kahn Gillmor
On Fri 2015-01-30 01:50:43 -0500, Yan Zhu wrote:
 Say that resource Y is a javascript file that listens for users typing
 in password fields and shows them a warning if the password is
 weak. The user verifies and loads the HTML page that includes Y but an
 attacker then blocks the request to fetch Y, so the user picks a weak
 password.

 My intuition is that most developers think about the security of their
 app as a whole, not the security of their app minus
 any-given-subset-of-resources.

I see what you're saying -- and javascript that is directly embedded in
the app would all definitely need to be loaded first (since we don't
know how it would affect the rest of the application).  I was thinking
of other resources that might be invoked or loaded later, via XHR or
dynamic script load other requests.

I suppose the question then arises of what to do if the app triggers an
XHR or dynamic script load for a piece of signed content, and that
signed content can't be fetched, the entire application would have to
block or something to avoid the scenario you describe.  That kind of UX
doesn't sound very web-like :/

--dkg



Re: Security use cases for packaging

2015-01-30 Thread Chris Palmer
On Thu, Jan 29, 2015 at 10:50 PM, Yan Zhu y...@yahoo-inc.com wrote:

 Say that resource Y is a javascript file that listens for users typing in 
 password fields and shows them a warning if the password is weak. The user 
 verifies and loads the HTML page that includes Y but an attacker then blocks 
 the request to fetch Y, so the user picks a weak password.

The application developer could cope with this in the top-layer code:

===
script
var passwordChecker = null;
...
/script
script src=password-checker.js/script
script
if (null == passwordChecker) {
// handle failure of security dependency
}
/script
===

Just as a native application developer should do:

===
void* passwordChecker = dlopen(password-checker.so, ...);
if (NULL == passwordChecker) {
// handle failure of security dependency
}
===

But,

 My intuition is that most developers think about the security of their app as 
 a whole, not the security of their app minus any-given-subset-of-resources.

You're probably right, about both web developers and native code developers.

But, if we provide a declarative interface for the package format that
allows developers to declare that a given dependency should be
pre-loaded when possible and mandatorily pre-loaded, they might be
more likely to use that than to write the tedious error-handling code
like that above. I.e. we can create good affordances, and thus get the
benefits of security and performance most of the time.



Re: Security use cases for packaging

2015-01-29 Thread Yan Zhu
chris palmer wrote:

 But other code from the same origin might not be signed, which could
 break the security assertion of code signing.


Maybe the code from the downloaded package has to be run from a local origin 
like chrome://*.



Re: Security use cases for packaging

2015-01-29 Thread Brad Hill
Paging (future Dr.) Deian Stefan to the ER...

Any thoughts on using COWL for this kind of thing, with a pinned crypto key
as a confinement label to be combined with the regular Origin label?

-Brad

On Thu Jan 29 2015 at 1:43:05 PM Yan Zhu y...@yahoo-inc.com wrote:

 chris palmer wrote:

  But other code from the same origin might not be signed, which could
  break the security assertion of code signing.


 Maybe the code from the downloaded package has to be run from a local
 origin like chrome://*.




Re: Security use cases for packaging

2015-01-29 Thread Chris Palmer
But other code from the same origin might not be signed, which could
break the security assertion of code signing.

The unit of signing should be the same as the unit of isolation, i.e.
the origin. Or, the origin should be expanded to include a 4th
element, the signing key(s). I don't know how to achieve that in a way
that does not bring with it the operational risks (bricking) of HPKP
and TACK.



Re: Security use cases for packaging

2015-01-29 Thread Devdatta Akhawe
 Maybe the code from the downloaded package has to be run from a local origin 
 like chrome://*.

Doesn't the same issue that Chris raised still exist? You need a unit
of isolation that says only code signed with this public key runs in
this isolation compartment. Chrome extensions have that model.
Whether we achieve this via origins, COWLs, or origin+key as the
identifier, is a separate question, but Chris' high level bit remains true.

cheers
dev



Re: Security use cases for packaging

2015-01-29 Thread Deian Stefan


Brad Hill hillb...@gmail.com writes:

 Paging (future Dr.) Deian Stefan to the ER...

 Any thoughts on using COWL for this kind of thing, with a pinned crypto key
 as a confinement label to be combined with the regular Origin label?


Thanks for paging me! I've thought about something like this---providing
some form of code integrity---in the context of COWL as well.

The idea was to grant a worker the privilege corresponding to the (hash
of the) source, in addition to its origin. This would allow a server to
verify if the code it is communicating with is trustworthy.
(COWL labels are not limited to origins.)

I really like Yan's use case. And I think it fits in pretty naturally
with COWL: the app, if verification succeeds, can be granted the
privilege corresponding to the (hash of the) crypto key:
Privilege(https://cryptomail.yahoo.com).and(app-key:...).
Other code from the same origin would only have 
Privilege(https://cryptomail.yahoo.com).

I think this may partly address Chris and Dev's concerns.  But deciding
when not to run the app code is still a question. Though I think the
github issue already brings this up.

Deian



Re: Security use cases for packaging

2015-01-29 Thread Yan Zhu
devdatta wrote:


 Maybe the code from the downloaded package has to be run from a local origin 
 like chrome://*.



 Doesn't the same issue that Chris raised still exist? You need a unit
 of isolation that says only code signed with this public key runs in
 this isolation compartment. Chrome extensions have that model.
 Whether we achieve this via origins, COWLs, or origin+key as the
 identifier, is a separate question, but Chris' high level bit remains true.


thanks, I meant a unique local (pseudo-)origin assigned to the downloaded 
package. Chrome extensions derive it purely from the public signing key IIRC; 
seems like that would suffice here too.


ilya wrote:
 Would it be possible to meet the security goals without assuming that the 
 response body is 

 part of the package? See [1] for background on why that's beneficial.. at 
 least for performance
 side of the story. I'm picturing a package description where each resource 
 has a SRI token, 

 plus a signature to authenticate the tree of resources / package description 
 itself? 
A signed manifest-like package description that lists the hash and location of 
every resource seems fine as long as all the resources are downloaded and 
verified before running the app. Perhaps this kills some of the performance 
benefits motivating packaging in the first place. :(



Re: Security use cases for packaging

2015-01-29 Thread Ilya Grigorik
Would it be possible to meet the security goals without assuming that the
response body is part of the package? See [1] for background on why that's
beneficial.. at least for performance side of the story. I'm picturing a
package description where each resource has a SRI token, plus a signature
to authenticate the tree of resources / package description itself?

[1] http://lists.w3.org/Archives/Public/public-web-perf/2015Jan/0008.html

On Fri, Jan 30, 2015 at 9:27 AM, Devdatta Akhawe dev.akh...@gmail.com
wrote:

  Maybe the code from the downloaded package has to be run from a local
 origin like chrome://*.

 Doesn't the same issue that Chris raised still exist? You need a unit
 of isolation that says only code signed with this public key runs in
 this isolation compartment. Chrome extensions have that model.
 Whether we achieve this via origins, COWLs, or origin+key as the
 identifier, is a separate question, but Chris' high level bit remains true.

 cheers
 dev




Re: Security use cases for packaging

2015-01-29 Thread Daniel Kahn Gillmor
On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote:
 A signed manifest-like package description that lists the hash and
 location of every resource seems fine as long as all the resources are
 downloaded and verified before running the app. Perhaps this kills
 some of the performance benefits motivating packaging in the first
 place. :(

Why would you need to fetch all the pieces before running the app?
Consider a manifest includes an integrity check covering resources X, Y,
and Z, but X is the only bit of code that runs first, and Y and Z aren't
loaded.

If you can validate the manifest, then you know you only run X if you've
verified the manifest and X's integrity.  If the user triggers an action
that requires resource Y, then you fetch it but don't use it unless it
matches the integrity check.

(i haven't developed webapps myself for ages, and the idea of a signed
webapp is relatively new to me, so feel free to explain any obvious part
that i'm missing)

--dkg


signature.asc
Description: PGP signature


Re: Security use cases for packaging

2015-01-29 Thread Yan Zhu
packaging and complicated signing is routine for most installable web apps 
and browser extensions; see 
https://developer.mozilla.org/en-US/docs/Signing_a_XPI for instance. Developers 
who build those might actually want the process to be less complicated. 

Given that the packaging spec lists installable web apps as a use case, it 
should probably define a signature format.

-Yan




On Thursday, January 29, 2015 7:12 PM, Michaela Merz 
michaela.m...@hermetos.com wrote:

Pardon my french, but the whole idea is ridiculous. Web development is
fluid and flexible. While I most certainly understand the idea and the
need for secured loadable code (AFAIK I brought up this issue about 2
months ago), packaging and complicated signing is counter productive.
What about external scripts like jquery? Do I really need to download a
complete package because I fixed a stupid typo in one of the scripts?

Maybe I am completely on the wrong track here (please correct me if I
am) - but I think signed code should be handled completely different -
thus preserving the flexibility of the LAMP/Script environment as we
know it.

Michaela




On 01/30/2015 03:22 AM, Daniel Kahn Gillmor wrote:
 On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote:
 A signed manifest-like package description that lists the hash and
 location of every resource seems fine as long as all the resources are
 downloaded and verified before running the app. Perhaps this kills
 some of the performance benefits motivating packaging in the first
 place. :(
 Why would you need to fetch all the pieces before running the app?
 Consider a manifest includes an integrity check covering resources X, Y,
 and Z, but X is the only bit of code that runs first, and Y and Z aren't
 loaded.

 If you can validate the manifest, then you know you only run X if you've
 verified the manifest and X's integrity.  If the user triggers an action
 that requires resource Y, then you fetch it but don't use it unless it
 matches the integrity check.

 (i haven't developed webapps myself for ages, and the idea of a signed
 webapp is relatively new to me, so feel free to explain any obvious part
 that i'm missing)

 --dkg



Re: Security use cases for packaging

2015-01-29 Thread Yan Zhu


On Thursday, January 29, 2015 6:25 PM, Daniel Kahn Gillmor 
d...@fifthhorseman.net wrote:

On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote:
 A signed manifest-like package description that lists the hash and
 location of every resource seems fine as long as all the resources are
 downloaded and verified before running the app. Perhaps this kills
 some of the performance benefits motivating packaging in the first
 place. :(

 Why would you need to fetch all the pieces before running the app?
 Consider a manifest includes an integrity check covering resources X, Y,
 and Z, but X is the only bit of code that runs first, and Y and Z aren't

 loaded. If you can validate the manifest, then you know you only run X if 
 you've
 verified the manifest and X's integrity.  If the user triggers an action
 that requires resource Y, then you fetch it but don't use it unless it
 matches the integrity check.

Say that resource Y is a javascript file that listens for users typing in 
password fields and shows them a warning if the password is weak. The user 
verifies and loads the HTML page that includes Y but an attacker then blocks 
the request to fetch Y, so the user picks a weak password.

My intuition is that most developers think about the security of their app as a 
whole, not the security of their app minus any-given-subset-of-resources.



Re: Security use cases for packaging

2015-01-29 Thread Michaela Merz

Pardon my french, but the whole idea is ridiculous. Web development is
fluid and flexible. While I most certainly understand the idea and the
need for secured loadable code (AFAIK I brought up this issue about 2
months ago), packaging and complicated signing is counter productive.
What about external scripts like jquery? Do I really need to download a
complete package because I fixed a stupid typo in one of the scripts?

Maybe I am completely on the wrong track here (please correct me if I
am) - but I think signed code should be handled completely different -
thus preserving the flexibility of the LAMP/Script environment as we
know it.

Michaela



On 01/30/2015 03:22 AM, Daniel Kahn Gillmor wrote:
 On Thu 2015-01-29 20:14:59 -0500, Yan Zhu wrote:
 A signed manifest-like package description that lists the hash and
 location of every resource seems fine as long as all the resources are
 downloaded and verified before running the app. Perhaps this kills
 some of the performance benefits motivating packaging in the first
 place. :(
 Why would you need to fetch all the pieces before running the app?
 Consider a manifest includes an integrity check covering resources X, Y,
 and Z, but X is the only bit of code that runs first, and Y and Z aren't
 loaded.

 If you can validate the manifest, then you know you only run X if you've
 verified the manifest and X's integrity.  If the user triggers an action
 that requires resource Y, then you fetch it but don't use it unless it
 matches the integrity check.

 (i haven't developed webapps myself for ages, and the idea of a signed
 webapp is relatively new to me, so feel free to explain any obvious part
 that i'm missing)

 --dkg