Date   

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


Re: Silver crypto (TLS) requirements - thoughts from Zephyr

David A. Wheeler
 

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.

 

I think it’s *too* restrictive, because our goal is to make sure that the overall system is secure.  If a library cannot get a higher badge, because it provides a clearly-documented lower-level interface, that will discourage the use of software that may in fact be better.

 

The original impetus for these TLS requirements, IIRC, was the botch in the built-in Python library where it accepted “https:” URLs, used the TLS protocol, but never checked the certificate, a sequence that led regular vulnerabilities.  See:

“PEP 476 -- Enabling certificate verification by default for stdlib http clients”

https://www.python.org/dev/peps/pep-0476/

 

But I think we overgeneralized.  The problem here was that the system accepted “https:” URLs without really implementing the full https protocol.

 

Indeed, even in Python, there’s a separation of “certificate checking” from “TLS implementation” because a lot of systems use specialized certificates.

 

--- David A. Wheeler

 

 


Re: Silver crypto (TLS) requirements - thoughts from Zephyr

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.

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

On Fri, Apr 13, 2018 at 10:00 AM, Wheeler, David A <dwheeler@...> wrote:
Kevin W. Wall:
> Instead, I think a better approach is to set up some sort of manual 'appeals
> process' whereby any given project can appear for an exclusion in regards
> to meeting some specific set of requirements and argue how it is either not
> applicable to them or how they have been the requirements _intent_ (i.e.,
> the spirit of the law) if not the letter of the law (requirement). I think that's
> preferable to removing / relaxing a requirement. This approach is common
> in policy governance. Unfortunately, it will require some "governing
> authority"
> to review the (hopefully) occasional appeal. One would hope that such
> appeals would be a relatively rare occurrence.

Our current appeals process has been to post proposed
changes/interpretations to this mailing list for comment
(skipping typos & such).  Then we (supporting the LF) make the final call.
Hence the email :-).

We've discussed several times creating a "governing body."
I (still) think it's a good idea, but we so seldom get questions like this
that it keeps getting pushed into the "sometime in the future" column.

I think you make a good point, though.  Maybe "we don't need to do it often"
is a selling point :-).

> In general, I am against relaxing the 2 silver requirements for Zephyr or any
> other project. And not just these TLS requirements, but conceptually I am
> against relaxing _any_ requirements for any level.
> If we have to do that, it seems to me that that's an admission that those
> requirements re too difficult for some particular level.

I have a slightly different view.  I think that if the requirements get relaxed
for *any* project, then *all* projects should have the opportunity to use those
relaxed requirements.  So if we really *do* relax a requirement, it should
be reflected in the criteria text that people read.  Nobody should have to
read the "special interpretations" of all other projects, they should be able to
read the criteria and see exactly what it means.
My goal is that over time this will clarify the "true intent"
of the underlying requirement.

--- David A. Wheeler

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


Re: Silver crypto (TLS) requirements - thoughts from Zephyr

David A. Wheeler
 

Kevin W. Wall:
Instead, I think a better approach is to set up some sort of manual 'appeals
process' whereby any given project can appear for an exclusion in regards
to meeting some specific set of requirements and argue how it is either not
applicable to them or how they have been the requirements _intent_ (i.e.,
the spirit of the law) if not the letter of the law (requirement). I think that's
preferable to removing / relaxing a requirement. This approach is common
in policy governance. Unfortunately, it will require some "governing
authority"
to review the (hopefully) occasional appeal. One would hope that such
appeals would be a relatively rare occurrence.
Our current appeals process has been to post proposed
changes/interpretations to this mailing list for comment
(skipping typos & such). Then we (supporting the LF) make the final call.
Hence the email :-).

We've discussed several times creating a "governing body."
I (still) think it's a good idea, but we so seldom get questions like this
that it keeps getting pushed into the "sometime in the future" column.

I think you make a good point, though. Maybe "we don't need to do it often"
is a selling point :-).

In general, I am against relaxing the 2 silver requirements for Zephyr or any
other project. And not just these TLS requirements, but conceptually I am
against relaxing _any_ requirements for any level.
If we have to do that, it seems to me that that's an admission that those
requirements re too difficult for some particular level.
I have a slightly different view. I think that if the requirements get relaxed
for *any* project, then *all* projects should have the opportunity to use those
relaxed requirements. So if we really *do* relax a requirement, it should
be reflected in the criteria text that people read. Nobody should have to
read the "special interpretations" of all other projects, they should be able to
read the criteria and see exactly what it means.
My goal is that over time this will clarify the "true intent"
of the underlying requirement.

--- David A. Wheeler


Re: Silver crypto (TLS) requirements - thoughts from Zephyr

Kevin W. Wall
 

David,

First, apologies for top posting. I don't usually do that, but I have
a bunch of emails to reply to tonight.

In general, I am against relaxing the 2 silver requirements for Zephyr
or any other project. And not just these TLS requirements, but
conceptually I am against relaxing _any_ requirements for any level.
If we have to do that, it seems to me that that's an admission that
those requirements re too difficult for some particular level.

Instead, I think a better approach is to set up some sort of manual
'appeals process' whereby any given project can appear for an
exclusion in regards to meeting some specific set of requirements and
argue how it is either not applicable to them or how they have been
the requirements _intent_ (i.e., the spirit of the law) if not the
letter of the law (requirement). I think that's preferable to removing
/ relaxing a requirement. This approach is common in policy
governance. Unfortunately, it will require some "governing authority"
to review the (hopefully) occasional appeal. One would hope that such
appeals would be a relatively rare occurrence. And as far as Zephyr is
concerned, it sounds as though they have already made an appeal and
sounds like their appeal is justified to me (which perhaps additional
documentation requirements as you mentioned).

My $.02,
-kevin

On Wed, Apr 11, 2018 at 5:43 PM, Wheeler, David A <@dwheeler> wrote:
We have a request for tweaking two silver requirements involving crypto
(specifically TLS) from the Zephyr project. Some details below. We don’t
have any particular text change proposals yet. If you have thoughts about
this, please comment or reply.



Thanks.



--- David A. Wheeler



======================================



The silver badge requirements include the following:

* The software produced by the project MUST, if it supports TLS, perform TLS
certificate verification by default when using TLS, including on
subresources. If the software does not use TLS, select "not applicable"
(N/A). [crypto_certificate_verification]

* 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 does not use TLS,
select "not applicable" (N/A).[crypto_verification_private]



However, we have some interesting comments from the Zephyr team (who are
working on a silver badge).



They note that, “Zephyr is an embedded operating system, and applications
would be bound to it, to go on a device to provide specific functions.”
Zephyr includes a code library that implements parts of TLS, but it’s not
*used* unless an application (running on top of Zephyr) calls this
TLS-related code. In Zephyr, the application needs to perform the
verification for the TLS certificates.



Of course, our real goal is that the "system as a whole" perform certificate
validation. From a security viewpoint, as long as it's *done* it's okay…
never mind *where* it’s done.



If Zephyr only provides the certificate information to something else, then
I think Zephyr needs to *clearly* document that the "other piece" *must*
complete the job of certificate validation, hopefully with clear warnings.
That's been a problem with Python, for example - people thought it was doing
certificate validation when it was *not*. IIRC, these criteria were
developed in part based on the experience with the Python libraries. But if
Zephyr makes it clear that it only does *part*, and does *NOT* do
certificate validation, then I think we should allow that kind of library
design. Basically, we want *apps* to do the full certificate validation…
but a library might not be doing the validation internally.



That said, we’ll need to be careful about any relaxing, including this case.
And if that’s just a terrible idea, I’d like to know that too.


_______________________________________________
CII-badges mailing list
CII-badges@...
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges
--
Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.


Silver crypto (TLS) requirements - thoughts from Zephyr

David A. Wheeler
 

We have a request for tweaking two silver requirements involving crypto (specifically TLS) from the Zephyr project.  Some details below.  We don’t have any particular text change proposals yet.  If you have thoughts about this, please comment or reply.

 

Thanks.

 

--- David A. Wheeler

 

======================================

 

The silver badge requirements include the following:

* The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select "not applicable" (N/A). [crypto_certificate_verification]

* 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 does not use TLS, select "not applicable" (N/A).[crypto_verification_private]

 

However, we have some interesting comments from the Zephyr team (who are working on a silver badge).

 

They note that, “Zephyr is an embedded operating system, and applications would be bound to it, to go on a device to provide specific functions.”  Zephyr includes a code library that implements parts of TLS, but it’s not *used* unless an application (running on top of Zephyr) calls this TLS-related code.  In Zephyr, the application needs to perform the verification for the TLS certificates.

 

Of course, our real goal is that the "system as a whole" perform certificate validation.  From a security viewpoint, as long as it's *done* it's okay… never mind *where* it’s done.

 

If Zephyr only provides the certificate information to something else, then I think Zephyr needs to *clearly* document that the "other piece" *must* complete the job of certificate validation, hopefully with clear warnings.  That's been a problem with Python, for example - people thought it was doing certificate validation when it was *not*.  IIRC, these criteria were developed in part based on the experience with the Python libraries.  But if Zephyr makes it clear that it only does *part*, and does *NOT* do certificate validation, then I think we should allow that kind of library design.  Basically, we want *apps* to do the full certificate validation… but a library might not be doing the validation internally.

 

That said, we’ll need to be careful about any relaxing, including this case.  And if that’s just a terrible idea, I’d like to know that too.


Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2018-03.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2018-02-272018-03-30
Total Projects13871459
Projects 25%+492526
Projects 50%+412449
Projects 75%+327357
Projects passing142159

Here are the projects that first achieved a passing badge in 2018-03:

  1. Graph at 2018-03-01 19:14:11 UTC
  2. Mission Pinball Framework at 2018-03-01 21:14:25 UTC
  3. cws at 2018-03-05 10:09:56 UTC
  4. libqmatrixclient at 2018-03-06 09:09:50 UTC
  5. AppArmor at 2018-03-06 15:01:48 UTC
  6. Multi VIM/Cloud at 2018-03-07 08:54:51 UTC
  7. ONAP Operations Manager at 2018-03-07 15:53:53 UTC
  8. wrike-bundle at 2018-03-07 20:03:49 UTC
  9. wrike-php-sdk at 2018-03-07 20:03:56 UTC
  10. wrike-php-jmsserializer at 2018-03-07 20:04:03 UTC
  11. wrike-php-guzzle at 2018-03-07 20:04:09 UTC
  12. wrike-php-library at 2018-03-07 20:04:17 UTC
  13. ONAP Optimization Framework (OOF) at 2018-03-13 18:24:33 UTC
  14. vitess at 2018-03-14 23:53:28 UTC
  15. distrobuilder at 2018-03-16 13:15:27 UTC
  16. VIPERBuilder at 2018-03-16 17:21:00 UTC
  17. Helpers for node-postgres for Lazy devs. 👽 at 2018-03-17 20:27:20 UTC
  18. MUSIC at 2018-03-20 17:29:21 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!


CII mailing list tweak planned by Linux Foundation IT department

David A. Wheeler
 

All, for your information:

The Linux Foundation's IT department has informed me that they are going to change how the mailing list works sometime in May 2018.

If you just read the emails you receive, you shouldn't notice a change. They've assured me that the archives will NOT be lost.

The management URLs will change from <https://lists.coreinfrastructure.org/mailman/listinfo/cii-discuss> to <https://lists.coreinfrastructure.org/g/cii-discuss>, but there will be a forwarding link - so if you use the old link you'll get forwarded to the new one.

If something DOES break, please let me know & I'll forward the issue to them.

--- David A. Wheeler


Native/fluent Spanish speaker willing to help translation?

David A. Wheeler
 

If you are a native/fluent Spanish speaker who’d be willing to do some translations for the best practices badge site, please contact me!  If you know someone trustworthy who fits that bill, please convince them to contact me.  We have some strings translated, but many aren’t done.

 

Thanks!

 

--- David A. Wheeler

 


I intend to allow "OWASP Juice Shop" badge to stand (project 223)

David A. Wheeler
 

The OWASP Juice Shop project has (after some time) gotten a badge, and I plan to let their application stand:

  https://bestpractices.coreinfrastructure.org/projects/223

 

This is an odd project for the badging application, because it is an *intentionally* insecure webapp, designed for security training.  You could certainly argue that it shouldn’t have a badge *because* it has known vulnerabilities that won’t be fixed (since that is its purpose).  They certainly had to provide extra text for some of the project justifications J.

 

However, in *context* I think it’s fine.  The project badge entry, and the project page itself, make it immediately clear that this is an "intentionally insecure webapp” – and thus the security expectations are different for it.  I understand from the description that they intend to leave vulnerabilities that are supposed to be there, and fix vulnerabilities that are not supposed to be there (or document them so that they're supposed to be there too).  That means they still have to deal with vulnerability reports.. it’s just that what they count as a vulnerability is a little different J.

 

In a broad sense this project helps our mission too, because we're all trying to help develop more secure software.  It’s very unlikely someone would field this project for “real” work (since it’s known to be vulnerable), so these vulnerabilities are unlikely to cause serious harm.  Indeed, the presence of these vulnerabilities should help train people.  Most industries have a variety of test objects & training materials that help people meet various objectives, and I think this project fits into that category.

 

I didn’t want people to think I’d ignored this issue, though.  If you have very strong objections, please let me know.

 

--- David A. Wheeler

 


Https links are not accepted in CII badging

Seshu m <seshu.kumar.m@...>
 

Hi

 

I finding issue while trying to update the https link in the CII badging for the following project

 

https://bestpractices.coreinfrastructure.org/en/projects/1702

 

Under the section,

The project sites (website, repository, and download URLs) MUST support HTTPS using TLS.

 

when we provide a https link (or keep it blank) , the website throws an error

 

// Given an http: URL.

               

 

This is effecting the score of the CII badging for ONAP SO project, request to help resolving the issue.

 


Best regards

Seshu Kumar M

Huawei Technologies India Pvt, Ltd.


本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

 


German translation for BadgeApp complete!

David A. Wheeler
 

A big “CONGRATS!” to the German translators, who just completed translating the BadgeApp into German.  Thank you very much!

 

We now have complete translations for German (de), French (fr), Japanese (ja), Russian (ru), and Chinese (zh-CN), in addition to English (en).

 

I am very grateful to all of our amazing and dedicated translators.  THANK YOU.

 

Also: We have some early work on Spanish (es) that *just* started up.  If any native Spanish speakers would like to help, please let me know!!

 

--- David A. Wheeler

 


Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2018-02.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2018-01-302018-02-27
Total Projects13281387
Projects 25%+467492
Projects 50%+389412
Projects 75%+304327
Projects passing136142

Here are the projects that first achieved a passing badge in 2018-02:

  1. VF-C (Virtual Function Controller Project) at 2018-02-05 08:13:27 UTC
  2. NetworkParser at 2018-02-09 14:54:26 UTC
  3. ONAP VNFSDK at 2018-02-09 20:44:34 UTC
  4. NEO•ONE at 2018-02-10 15:16:47 UTC
  5. Pipeline at 2018-02-15 11:42:02 UTC
  6. Hyperledger Composer at 2018-02-27 10:33:32 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!


Move from CVSS version 2.0 to version 3.0?

David A. Wheeler
 

I think we should switch from Common Vulnerability Scoring System (CVSS) version 2.0 to version 3.0 in the criteria.  Any objections?

 

We don’t need to do this quickly, but I’d like it to be in the queue.  If people have opinions on how fast we should do this, I’d like to know.  I want to be cautious about anything that would affect existing badge-holders, but I do not think this will affect any current badge-holders.

 

Details below.

 

--- David A. Wheeler

 

=== DETAILS ===

 

A very few of our criteria mention CVSS.  For example, [dynamic_analysis_fixed] says this:

CRITERION: “All medium and high severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed.”

DETAILS: A vulnerability is medium to high severity if its CVSS 2.0 base score is 4. If you are not running dynamic code analysis and thus have not found any vulnerabilities in this way, choose "not applicable" (N/A).

 

CVSS version 3 has been around for a while, but we didn’t use it because the NIST National Vulnerability Database (NVD) only provided version 2 data, and not version 3 data.  However, NIST has since added support for version 3.  More info:

https://nvd.nist.gov/vuln-metrics/cvss

 

This should have little effect in practice.  CVSS version 3 rates some vulnerabilities more risky than version 2 did (in particular, Heartbleed gets a higher risk score under version 3 compare to version 2).  That said, if a project has that many vulnerabilities where the CVSS version change matters, that’s a problem in itself.

 


BadgeApp performance

David A. Wheeler
 

I recently made some tweaks that seem to really bump up website performance.

 

By adding some “preload” statements and a fragment cache, the front page on the “master” branch is getting webpagetest.org median performance figures of load time 0.730s, start render 0.567s.  That’s with a fast Internet connection assuming the site is all-the-way-up, but that’s also from a cold start (“never-seen-site before”).  Once a user visits the site at all, much of the “big stuff” (like CSS and JavaScript) is cached, which makes performance even better.  Details here:

https://www.webpagetest.org/result/180214_2T_c03d80608ab7e2531d71a448613cb023/

 

The site doesn’t need to be blazingly fast, we just don’t want people to turn away because of interminable page loads.  I think ideal is under 1s, and we must be under 2s response in such conditions.  We’re easily meeting those requirements.

 

In the longer term I intend to replace the font-awesome font icon file, which is huge & doesn’t play nicely with dyslexic fonts, with loading specific SVGs (or maybe SVG sprites).  That should reduce the cold start page load time even further.

 

--- David A. Wheeler

 


Spanish translation ongoing!

David A. Wheeler
 

I’d like to say a quick “THANKS!” to Borja Martín, who has volunteered to work on a Spanish translation of the BadgeApp.  He has already begun; once it’s further along, I look forward to adding to the list of selectable options.

 

While I’m at it: a BIG THANK YOU to all of you who’ve helped translate, or in any way helped in developing the BadgeApp or its criteria.  Like any OSS project, it takes a lot of hands to make something successful, and I’m grateful to everyone.

 

--- David A. Wheeler


Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2018-01.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2017-12-302018-01-30
Total Projects12481328
Projects 25%+442467
Projects 50%+364389
Projects 75%+287304
Projects passing130136

Here are the projects that first achieved a passing badge in 2018-01:

  1. in-toto at 2018-01-05 21:31:54 UTC
  2. containerd at 2018-01-09 15:11:14 UTC
  3. Seriously at 2018-01-10 16:47:33 UTC
  4. bin2c Conversion Tool. at 2018-01-19 11:08:28 UTC
  5. MSB(Microservices Bus) at 2018-01-30 02:33:00 UTC
  6. cli at 2018-01-30 12:30:32 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!


Video: Quick demo on how to start getting a CII Best Practices badge

David A. Wheeler
 

I just posted a very short & simple video titled

“Quick demo on how to start getting a CII Best Practices badge”

  https://www.youtube.com/watch?v=dhLYLpsvvc0

 

There’s nothing fancy here – I didn’t even create a title screen or put in intro music.  But some people find it easier to learn by watching others, and this a start towards that.

 

--- David A. Wheeler

 


Deleting a project now requires justification

David A. Wheeler
 

The best practices production site now has a new form for those who ask to delete projects (when they have the permissions necessary to do so). The system now requires that there be some text that explains *why* they are deleting a project entry. As I noted earlier, I'm sure we can't please everyone, but if there's a common issue we can resolve in the future, this will at least help us find out *why* someone is deleting their project entry. This new form also makes it harder to accidentally delete a project.

We continue to add projects, and more projects are getting badges. You can see the details here:
https://bestpractices.coreinfrastructure.org/project_stats
As of yesterday, 1294 projects are participating, and of those, 133 having passing badges.

--- David A. Wheeler


Another citation of the best practices badge project!

David A. Wheeler
 

FYI, Mike Samuel let me know that he said nice things about the best practices badge project in his article "A Roadmap for Node.js Security". It is part of a larger discussion about how to aggregate information that is useful when picking third-party dependencies or making build vs. reuse decisions.

More details:
https://nodesecroadmap.fyi/chapter-3/knowing_dependencies.html

--- David A. Wheeler