Topics

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.

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.

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

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

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