Subject: Re: [Cfrg] On "non-NIST"

From: Peter Gutmann <[email-masked]>
Date: Sat, 28 Feb 2015 08:59:42 +0000

Paul Hoffman <[email-masked]> writes:

>The term "non-NIST" is predictive, and the crypto community kinda sucks at
>predictions. We have no idea what NIST will do in the future if a bunch of
>IETF WGs adopt specific elliptic curves that are not P256/P384.

Why is NIST seen as the ultimate arbiter of what's appropriate though?  Look
at what's happened with SHA-3, if you look at what independent standards
efforts are going with it's pretty much anything but Keccak (Blake2 seems to
be the most popular at the moment).

So while NIST's idea of the next hash standard may be Keccak, the industry's
one looks like being Blake2, or at least not Keccak.  It's a variation of the
old "what if they had a war and no-one came", if NIST declares the standard to
be X and no-one wants it then that's perfectly OK, the usual suspects who are
in it for the USG handouts will do X (Suite B anyone?) and everyone else can
ignore it and use the better alternative.

Peter.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 28 Feb 2015 07:41:05 -0800

On Feb 28, 2015, at 12:59 AM, Peter Gutmann <[email-masked]> wrote:
> Why is NIST seen as the ultimate arbiter of what's appropriate though?  

Not "the", but "an". The reason is that NIST controls what can and cannot be given a FIPS-140 certification, and that certification is considered important both by companies who want to sell to the US Govt and companies that use their certification as a statement that "we did it right". If you make an HSM that uses an algorithm not allowed by NIST, you cannot get it certified in the CMVP regime. Thus, when NIST is slow to keep up with the best practices adopted by the community, it becomes a roadblock to deploying better crypto.

This is why we hope that, when this RG finally moves on both the the curve and the signing algorithm, NIST adds those to its list of acceptable crypto for the FIPS 140 testing. If they don't, people can still deploy it, but deployment will be hampered.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 28 Feb 2015 11:02:17 -0500

On Sat, Feb 28, 2015 at 10:41 AM, Paul Hoffman <[email-masked]>
wrote:

> Not "the", but "an". The reason is that NIST controls what can and cannot
> be given a FIPS-140 certification, and that certification is considered
> important both by companies who want to sell to the US Govt and companies
> that use their certification as a statement that "we did it right". If you
> make an HSM that uses an algorithm not allowed by NIST, you cannot get it
> certified in the CMVP regime. Thus, when NIST is slow to keep up with the
> best practices adopted by the community, it becomes a roadblock to
> deploying better crypto.

That overstates it.

I need my HSMs validated by some independent party. NIST has an existing,
widely respected infrastructure. The fact that NIST certification is
necessary for US govt use is not the issue here.

We need someone to do the work, there is a limited number of parties with
the resources, skills and authority to do the job. If NIST is not going to
do the job then we would need to find someone else. That is not impossible
but NIST is the default.

So the practical upshot here is that NIST is a stakeholder because we would
like their help. They are also a standards body in their own right (though
not a multi-stakeholder one). So it would be even more helpful if they gave
an indication that the new curves are at least equally acceptable as the
old for US govt. work.

NIST is a stakeholder here. They are not the only one but they are one of
the few stakeholders that is likely to have a strong opinion.

If NIST or Microsoft or Google was to say that they cared a really great
deal about P448 or P521 then that should in my view carry rather more
weight than a bunch of folk with either a mild preference for one or the
other.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 28 Feb 2015 09:17:35 -0800

> Not "the", but "an". The reason is that NIST controls what can and cannot be given a FIPS-140 certification, and that certification is considered important both by companies who want to sell to the…

This is factually untrue: CMVP certified modules are permitted to
implement other algorithms: they just can't be in FIPS mode when those
are used. I also don't see how NIST approval or lack thereof slowed
down RC4 deployment or accelerated SHA1 replacing MD5.

The reality is lots of new designs are using Curve25519 and Ed25519.
That's because of factors like simple design of APIs, high
performance, and very good security. Standards body acceptance is not
a concern here. Just as the reality is that E-521 was picked by
Brazil, while the new GOST is still being worked on, and the upper
size limit is just a random number. But never mind reality: we've got
to expose "signs of strength". We need big numbers for marketing:
never mind attackers can't break authentication in the future, while
mobile devices already struggle to validate certificates. We need to
vote on endianness: nothing more needs to be said.

Is anyone surprised we've become a punchline?

Sincerely,
Watson Ladd

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 28 Feb 2015 12:39:07 -0500

On Sat, Feb 28, 2015 at 12:17 PM, Watson Ladd <[email-masked]> wrote:

> > Not "the", but "an". The reason is that NIST controls what can and
> cannot be given a FIPS-140 certification, and that certification is
> considered important both by companies who want to sell to the US Govt and
> companies that use their certification as a statement that "we did it
> right". If you make an HSM that uses an algorithm not allowed by NIST, you
> cannot get it certified in the CMVP regime. Thus, when NIST is slow to keep
> up with the best practices adopted by the community, it becomes a roadblock
> to deploying better crypto.
>
> > This is why we hope that, when this RG finally moves on both the the
> curve and the signing algorithm, NIST adds those to its list of acceptable
> crypto for the FIPS 140 testing. If they don't, people can still deploy it,
> but deployment will be hampered.
> >
> > --Paul Hoffman

US NIST chose P521
Brazil chose P521

Isn't that a pattern emerging?

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 28 Feb 2015 09:40:39 -0800

On Feb 28, 2015, at 9:17 AM, Watson Ladd <[email-masked]> wrote:
> are used.

That sentence assumes a few things: an HSM that has multiple signing algorithms *and* a lab that would allow non-certified signing algorithms to be within the crypto module that gets the Level 2+ certification *and* the CMVP program allowing the lab's evaluations. To the best of my knowledge, this has never happened. (Disclaimer: NIST once paid me to become an expert on the CMVP process and how crypto vendors and labs dealt with it, but I have not kept my day-to-day knowledge of it up to date in recent years.)

What you describe is quite common in devices that get Level 1 certifications, but it is not clear that something that normally is expected to have a Level 2+ validation, specifically like HSMs, would be able to do so.

--Paul Hoffman

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 28 Feb 2015 15:02:04 -0800 (PST)

> vote on endianness: nothing more needs to be said.

  Don't change things for trivial reasons, or no reason at all, and
there won't be a need to vote on them.

> Is anyone surprised we've become a punchline?

  To quote Tonto: what do you mean "we" white man?

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 28 Feb 2015 15:41:22 -0800

> What you describe is quite common in devices that get Level 1 certifications, but it is not clear that something that normally is expected to have a Level 2+ validation, specifically like HSMs, wou…

Safenet's Luna SA Network-attached HSM claims FIPS 140-2 Level 3
certification and support Brainpool. Granted, I only know about this
because it's the one Amazon provides and I had occasion to read the
documentation.

But you're right that somehow we may need HSM and certification. But
this works fine for Brainpool, despite not NIST, and there are
alternatives to FIPS testing for HSMS for use with PKI.

Source: http://www.safenet-inc.com/data-encryption/hardware-security-modules-hsms/luna-hsms-key-management/luna-sa-network-hsm/#content-left

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Sat, 28 Feb 2015 23:51:45 +0000

On Feb 20, 2015, at 12:41 PM, Paul Hoffman wrote:
> That sentence assumes a few things: an HSM that has multiple signing
> algorithms *and* a lab that would allow non-certified signing algorithms
> to be within the crypto module that gets the Level 2+ certification *and*
> the CMVP program allowing the lab's evaluations. To the best of my
> knowledge, this has never happened.

We have a number of level 2 certified devices that can be configured with
non-FIPS approved algorithms.  The lab (and the CMVP) were satisfied with
documentation that said "to be in FIPS mode, the device must be configured
this way".  Presumably the same logic can work for an HSM.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 28 Feb 2015 16:46:40 -0800

> this way".  Presumably the same logic can work for an HSM.

These are good to hear, and I apologize for my lack of up-to-date information on getting Level 2+ certification in mixed-crypto devices. I still hope NIST will quickly allow certification of whatever curves and signature algorithms the CFRG recommends to the TLS WG, of course, but it does not seem like a blocking factor for vendors to include them in their devices.

--Paul Hoffman