boringcrypto+fipsonly: way more strict than fips 140-2?

[Riccardo Raccuia]

Hello golang-nuts, 

I haven't found a single discussion about this so out of pure curiosity i'm going to try and shoot the question.

My intent is not to start a debate on any cipher/mode/signature algs' weaknesses but merely to understand some the limitations that are enforced when using the "crypto/tls/fipsonly" package of the famous boringcrypto fork of golang.

From src/crypto/tls/boring.go: 

// default FIPSCipherSuites is the FIPS-allowed cipher suites,

// in preference order (most preferable first).

var defaultFIPSCipherSuites = []uint16{

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,

TLS_RSA_WITH_AES_128_GCM_SHA256,

TLS_RSA_WITH_AES_256_GCM_SHA384,

}

Although the boringcrypto's NIST certificate mentions a number of approved AES modes (e.g. CBC), the GCM mode seems is the only mode that will be allowed for TLS 1.2.

Also on signature algorithms, this is what we find later in the same source file: 

// supportedSignatureAlgorithms returns the supported signature algorithms.

// It knows that the FIPS-allowed ones are all at the beginning of

// defaultSupportedSignatureAlgorithms.

func supportedSignatureAlgorithms(version uint16) []SignatureScheme {

all := defaultSupportedSignatureAlgorithms

if version < VersionTLS13 {

all = defaultSupportedSignatureAlgorithmsTLS12

}

if !needFIPS() {

return all

}

i := 0

for i < len(all) && all[i] != PKCS1WithSHA1 {

i++

}

return all[:i]

}

PKCS1WithSHA1 is still a perfectly valid FIPS 140-2 signature algorithm but here it is being explicitly excluded from the supported algs.

Really, I understand and agree that we're much better off without CBC and SHA1, although sometimes one might not have a choice.

Does anyone know the reasons behind the much stricter limitations compared to FIPS 140-2 when in fipsonly mode?

Thanks !!

[Wojciech S. Czarnecki]

On Wed, 20 Mar 2019 03:10:37 -0700 (PDT)
Riccardo Raccuia <rira...@gmail.com> wrote:

> My intent is not to start a debate on any cipher/mode/signature algs'
> weaknesses but merely to understand some the limitations that are enforced
> when using the "crypto/tls/fipsonly" package of the famous boringcrypto
> fork of golang.

In short: FIPS is all about about bureaucracy, "US National Security"
and $$$ that follows. Real soundness and code security is important
but is of second thought to above.

https://blog.ipswitch.com/fips-validated-vs-fips-compliant

Validated is exact version of boringcrypto: 24e.....d6f5
It will not lose its validation even if it has a bug.
If it will fix this bug its validation is lost.

> Really, I understand and agree that we're much better off without CBC and
> SHA1, although sometimes one might not have a choice.

If you need something that NIST allows you are free to make NIST
application for your own changes / configuration of an open source software.
It was done eg. for Crypto++ in the past.

> Does anyone know the reasons behind the much stricter limitations compared
> to FIPS 140-2 when in fipsonly mode?

Adam Langley is a well recognized expert in the field. I trust in his decisions.

> Thanks !!

Hope this helps.

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

[Eric Grosse]

On Wednesday, March 20, 2019 at 12:07:49 PM UTC-7, ohir wrote:

Adam Langley is a well recognized expert in the field. I trust in his decisions.

+1 

 

Validated is exact version of boringcrypto: 24e.....d6f5
It will not lose its validation even if it has a bug.
If it will fix this bug its validation is lost.

Another expert in the field that I know and trust is Donna Dodson,

https://www.nist.gov/about-us/nist-awards/donna-dodson-nist-fellow 

Donna assures that security bug fixes to validated security software

should not be viewed as breaking the validation.  That would be

perverse and NIST will back you up if some crazy auditor challenges

you.

It could be a matter of debate whether disallowing SHA1 is strictly

speaking a bug fix in the same sense as preventing a buffer overflow.

But again I'm sure you could win an argument with an auditor.

 

[Wojciech S. Czarnecki]

On Thu, 21 Mar 2019 16:57:14 -0700 (PDT)
Eric Grosse <gro...@gmail.com> wrote:

I apologize for being too terse.

I in no way meant to undermine the FIPS procedure's value as a remedy to the
real problem of knowing what code (and/or hardware) runs in security sensitive
environments. Just stated the obvious, that for the vendor it is the much
bureaucratic process that cost money and time.

> > It will not lose its validation even if it has a bug.
> > If it will fix this bug its validation is lost.

> But again I'm sure you could win an argument with an auditor.

I meant that after a bugfix release vendor has to submit its code again for review.

The Implementation Guidance section G.8 “Revalidation requirements”
was worked on 2016-2018 and is in force for less than a year now.

Even with its 3A path (for CVE reported holes with small and obvious fixes)
that is now exempt from the NIST fee, walking 3A still bears costs of staff
and time. Only after that certificate will be updated **and only then** your bugfix
version will be considered validated and buggy old version invalidated.

If for whatever reason you can not get to the 3A fast lane, you need to be
prepared to fees and time of 3SUB (while the old version still is "validated").

TC,

P.S. this clarification should be the last message in this thread as it is not
really on topic for go-nuts list. Feel free to discuss it further in private, though :).