Topics

Silver crypto (TLS) requirements - thoughts from Zephyr

Kate Stewart
 

Dan Kohn:
> I don't see a big upside in relaxing. I would prefer for Zephyr to have a passing badge, and then an application on top of Zephyr (or, alternatively, the whole system) could get certified with the silver badge, if it wanted to.

Challenge here is that Zephyr can't get a passing badge as the criteria is specified without writing 
and incorporating a reference application using its services.

Its not so much relaxing the criteria, as taking into account there are different types of software at play.
Operating systems and possibly language libraries are meant to have applications running on them, and 
call services they provide to enable functionality.  As a result,  its not clear how they can meet the criteria 
as specified without a contrived example application being  bundled/available with them as a reference 
(or at least that's the only path we've thought of so far). 

CII criteria here is specified for a running system,  which translates to the application perspective,  not
the OS/Library perspective.    

Are there any other OSes or language specific libraries,  that have met these two specific criteria
that you can point us to,  to see how they handled the criteria?

Thanks, Kate

Dan Kohn
 

I mistakenly thought the criteria was preventing Zephyr from getting a silver badge, not just a passing badge. I withdraw my comment.

--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com

On Mon, Apr 16, 2018 at 1:41 PM, Kate Stewart <kstewart@...> wrote:
Dan Kohn:
> I don't see a big upside in relaxing. I would prefer for Zephyr to have a passing badge, and then an application on top of Zephyr (or, alternatively, the whole system) could get certified with the silver badge, if it wanted to.

Challenge here is that Zephyr can't get a passing badge as the criteria is specified without writing 
and incorporating a reference application using its services.

Its not so much relaxing the criteria, as taking into account there are different types of software at play.
Operating systems and possibly language libraries are meant to have applications running on them, and 
call services they provide to enable functionality.  As a result,  its not clear how they can meet the criteria 
as specified without a contrived example application being  bundled/available with them as a reference 
(or at least that's the only path we've thought of so far). 

CII criteria here is specified for a running system,  which translates to the application perspective,  not
the OS/Library perspective.    

Are there any other OSes or language specific libraries,  that have met these two specific criteria
that you can point us to,  to see how they handled the criteria?

Thanks, Kate


_______________________________________________
CII-badges mailing list
CII-badges@lists.coreinfrastructure.org
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges


Kate Stewart
 



On Mon, Apr 16, 2018 at 1:25 PM, Dan Kohn <dan@...> wrote:
I mistakenly thought the criteria was preventing Zephyr from getting a silver badge, not just a passing badge. I withdraw my comment.

Sorry my mistake.   I overloaded the term passing to 
mean "passing for a silver" badge in the context of this thread.

Zephyr already has had the "passing" badge for quite a while,  and we're 
93% of the way there for a Silver badge.

Dan Kohn
 

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.

--
Dan Kohn <dan@...>
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com

On Mon, Apr 16, 2018 at 2:35 PM, Kate Stewart <kstewart@...> wrote:


On Mon, Apr 16, 2018 at 1:25 PM, Dan Kohn <dan@...> wrote:
I mistakenly thought the criteria was preventing Zephyr from getting a silver badge, not just a passing badge. I withdraw my comment.

Sorry my mistake.   I overloaded the term passing to 
mean "passing for a silver" badge in the context of this thread.

Zephyr already has had the "passing" badge for quite a while,  and we're 
93% of the way there for a Silver badge.


Kate Stewart
 



On Mon, Apr 16, 2018 at 1:39 PM, Dan Kohn <dan@...> 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.

I think it useful to maintain the scope of a badge associated within a single project, rather than 
combinations of projects.   To that end,  can the two criteria be rephased to take into account the difference
between applications and projects that supply services to applications?

David Brown
 

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]@dankohn> 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 A. Wheeler
 

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
 

David

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

Mark

On Mon, Apr 16, 2018 at 2:44 PM, Wheeler, David A <dwheeler@...> wrote:
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

_______________________________________________
CII-badges mailing list
CII-badges@lists.coreinfrastructure.org
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges

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

Andy Gross
 

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

Andy Gross
 

On 3 May 2018 at 15:28, Andy Gross <andy.gross@...> wrote:
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)>

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?

Best regards,

Andy Gross
Zephyr Project
 

Daniel Stenberg
 

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

David Brown
 

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

Daniel Stenberg
 

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