Silver crypto (TLS) requirements - thoughts from Zephyr
|
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,
toggle quoted messageShow quoted text
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@ida.org> wrote:
We have a request for tweaking two silver requirements involving crypto --
Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall NSA: All your crypto bit are belong to us.
|
|
|
|
Kevin W. Wall:
Instead, I think a better approach is to set up some sort of manual 'appealsOur 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 anyI 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
|
|
|
|
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:
|
|
|
|
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
|
|
|