On Mon, Apr 16, 2018 at 01:52:12PM -0500, Kate Stewart wrote:

On Mon, Apr 16, 2018 at 1:39 PM, Dan Kohn <[1]dan@linuxfoundation.org> wrote:

OK, then I'm suggesting that perhaps Zephyr should only be able to get a
passing badge, but the combination of Zephy + a suitable bundled
application could get silver.

However, I don't feel strongly about this.

A "suitably bundled application" could open the door for a dependency outside
the project to be considered in assessment.
There's no real way of expressing this in the system as it stands today.   ie. 
if project "a" is "passing",   
application "b" relying on services from project "a" is "silver", but
application "b" relying on services from project "c" doesn't pass.

This probably starts to become more of a Zephyr decision, but what I'm
trying to make is so that we have a "demo" application that
demonstrates the full solution, and does all that is needed to be
secure. If we do this right, this application won't be very large,
and I see no reason to not include it in the sample applications in
the tree.

Somewhat unrelated to the security aspects themselves, I'd like this
application itself to be able to be fairly small, meaning that a lot
of the functionality, such as certificate verification, would be taken
care of by the libraries within Zephyr.

I'm not sure how this will fit in with what could be considered
passing the Silver requirements, though.

David

David Brown:

This probably starts to become more of a Zephyr decision, but what I'm
trying to make is so that we have a "demo" application that demonstrates
the full solution, and does all that is needed to be secure. If we do this
right, this application won't be very large, and I see no reason to not
include it in the sample applications in the tree.

That's an interesting approach, but I'm not sure requiring a project to create a "demo"
application just to pass some criteria really adds value. We want the criteria to
add value! If you need to do that for testing, though, I can see value in
a requirement like that.

--- David A. Wheeler

Mark Rader:

We may want to start caveating the advanced criteria for areas where a specific point may not apply.

We do that already; several criteria have "if" clauses. E.g.:
* If the software produced by the project requires building for use, the project MUST provide a working build system that can automatically rebuild the software from source code. [build]
* The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language. [warnings]

Suggestions on an "if" clause for this case are welcome; we can then discuss them.

--- David A. Wheeler

David Wheeler:

We do that already; several criteria have "if" clauses. E.g.:
* If the software produced by the project requires building for use, the project
* MUST provide a working build system that can automatically rebuild the
* software from source code. [build]
* The project MUST enable one or more compiler warning flags, a "safe" language
* mode, or use a separate "linter" tool to look for code quality errors or
* common simple mistakes, if there is at least one FLOSS tool that can implement
* this criterion in the selected language. [warnings]

Suggestions on an "if" clause for this case are welcome; we can then discuss
them.

We've discussed this at some length in the Zephyr Security subcommittee and have
come up with the following changes:

I've listed the two requirements (Silver - Security #7 and #8) below with the
addition of an if clause to cover the Zephyr RTOS case. The changes are
encased in << >>.

The software produced by the project MUST, if it supports TSL, perform TLS
certificate verification by default when using TLS, including on subresources.
<<If the software is not an application that directly uses TLS select “not
applicable” (N/A).>>


The software produced by the project MUST, if it supports TLS, perform
certificate verification before sending HTTP headers with private information
(such as secure cookies). <<If the software is not an application that directly
uses TLS, select "not applicable" (N/A)>>

Regards,

Andy Gross
Linaro
Zephyr Security Subcommittee chair

On Tue, 26 Jun 2018, Andy Gross wrote:

The software produced by the project MUST, if it supports TSL, perform TLS certificate verification by default when using TLS, including on subresources. <<If the software is not an application that directly uses TLS select “not applicable” (N/A).>>

The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). <<If the software is not an application that directly uses TLS, select "not applicable" (N/A)>

I haven't seen any response or activity on this thread so I'm pinging this to refresh the conversation. Would the above changes to the requirements be palatable for the Silver TLS criteria?

I don't understand the proposed changes. They seem to introduce a huge loop hole in the TLS requirements.

First: certificate verification is not just for protecting "sensitive data" that client may send (and even determining what is "sensitive" is often very hard); it also makes sure that what is received can be trusted to be from the right sender and thus the contents can be trusted to be what the sender intended it to be etc.

Then, I don't see how you can defer that requirement to someone else and get away with it. As the suggested phrasing of this requirement goes, you can as a work-around use a completely insecure TLS-using *separate* library/project but as long as I write my application to not "directly use TLS" I can just select N/A on this requirement and get a pass.

--

/ daniel.haxx.se

On Wed, Jun 27, 2018 at 08:06:57AM +0200, Daniel Stenberg wrote:

I haven't seen any response or activity on this thread so I'm pinging this
to refresh the conversation. Would the above changes to the requirements be
palatable for the Silver TLS criteria?

I don't understand the proposed changes. They seem to introduce a huge loop
hole in the TLS requirements.

First: certificate verification is not just for protecting "sensitive data"
that client may send (and even determining what is "sensitive" is often very
hard); it also makes sure that what is received can be trusted to be from the
right sender and thus the contents can be trusted to be what the sender
intended it to be etc.

Then, I don't see how you can defer that requirement to someone else and get
away with it. As the suggested phrasing of this requirement goes, you can as a
work-around use a completely insecure TLS-using *separate* library/project but
as long as I write my application to not "directly use TLS" I can just select
N/A on this requirement and get a pass.

The issue here is how to address things that aren't "applications". A
project that is either a library, or an os/platform isn't necessarily
in a position itself to enforce certificate verification, and it is up
to whatever application someone writes using this library or platform.

In our specific case, Zephyr includes the mbed TLS library. We can
certainly make sure that any helper libraries we provide do proper
certificate validation, as well as make sure that the sample
applications do things correctly. But, ultimately, it is just a
library, and it is up to a given application to use it correctly.

How do we best capture this with CII? The current wording effectively
excludes libraries or operating systems from reaching Silver, which, I
argue makes silver less useful. But, are there things these types of
projects should do to make it more likely that applications using it
will do things correctly?

I don't think we want to allow an application to get past this
requirement, as you've stated, but I do think we need to capture that
some projects do include TLS, but aren't themselves using that
library.

David

On Wed, 27 Jun 2018, David Brown wrote:

The issue here is how to address things that aren't "applications". A project that is either a library, or an os/platform isn't necessarily in a position itself to enforce certificate verification, and it is up to whatever application someone writes using this library or platform.

In our specific case, Zephyr includes the mbed TLS library. We can certainly make sure that any helper libraries we provide do proper certificate validation, as well as make sure that the sample applications do things correctly. But, ultimately, it is just a library, and it is up to a given application to use it correctly.

I have the exact same situation in curl. We provide a library and a tool. That both speak TLS and both can disable certificate verification.

How do we best capture this with CII? The current wording effectively excludes libraries or operating systems from reaching Silver, which, I argue makes silver less useful. But, are there things these types of projects should do to make it more likely that applications using it will do things correctly?

I think if the application, library, tool, or framework that uses TLS does verifies certificates by default then it satisfies the requirement.

Sure, almost everything that speaks TLS also allows the user to shoot themselves in the foot and disable the verification but I consider that secondary and not as important as what it does if use it without anything explicitly disabled or switched off.

At least that's how I've viewed the requirements for curl.

--

/ daniel.haxx.se