[openssl-users] Key Deriviation Function Tests for TLS

[Jakob Bohm]

On 30/09/2015 14:28, Steve Marquess wrote:
> On 09/30/2015 03:50 AM, Jakob Bohm wrote:
>> Dear Steve,
>>
>> Have you considered that their contribution may be of value
>> to the next/future major version of the open source FIPS
>> module (which would presumably involve a fresh submission
>> under updated FIPS validation rules).
>>
>> This would obviously be a different code branch from
>> maintenance/change letter updates to the current module.
> We have indeed. As noted already that code will be of no value until we
> can actually run it through a validation ourselves. Our days of
> committing speculative code that "might come in handy someday" are
> behind us.
For branches expected to be promoted to release "eventually"
(like the non-fips master branch) this is good policy.  However
it is also good policy to have, outside such branches, a place
to gather up snippets (own or contributed) that might come
handy some day, such as a constant time memcmp (before it
became needed in a recent security patch) or an implementation
of an SHA-3 candidate (before NIST selected the final SHA-3) etc.

For an open source project, such unpolished unintegrated code could
live in the bugtracker or in a special "experiments" git branch.
The code in such a place would have the common characteristic of
fully clarified licensing (PD, BSD, classic OpenSSL/SSLeay, foundation
contributed, etc.), such that if/when the need arises, there is no
need to track down and negotiate with the original contributor (think
of pre-Oracle Sun contributions or pre-RSA EAY contributions).

Under the new "contribution agreement" scheme, publishing such items
early would also make them available to users even if the UK's GCHQ
suddenly imposes draconian restrictions on the UK-based foundation,
as it would make them legally available to continuation projects based
in different jurisdictions, just as the original EAY-style licenses
made the code available for continuation projects outside Australia.
>
> We also have plans for a significant rewrite of the FIPS module from its
> current form, and it's unlikely any third party submissions would fit
> that vision.
Interesting, I wonder if those plans include my previously
posted ideas:

  - Having the FIPS module contain no direct system calls,
   only callbacks to its client.  This would mean one FIPS
   blob per instruction set, not one per target platform.
   (Bureaucracy would still require enumeration of platform
   environments, but the change to add a new environment for
   the same instruction set would consist only of adding it
   to the list, no changes to policy or code).
  - Having the FIPS module be position independent, such
   that the integrity hash becomes immune to ASLR.
  - Having the FIPS blob be application independent, such
   that the correct integrity hash can be determined at
   FIPS module build time without using special application
   link steps.
  - Including the FIPS blob hash for known good compilers
   in the policy document, while still having the
   compilation-proven correspondence to source.

> Of course any third party (Cisco for instance) is free to publish
> patches or even a compete open source FIPS module themselves, and deal
> with the inevitable onslaught of requests for support. I get those
> almost daily, usually in the form of "we're trying to do our own
> validation and need a little help...".
>
> -Steve M.
>


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150930/4cadb4ea/attachment.html>