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

From: Johannes Merkle <[email-masked]>
Date: Mon, 2 Mar 2015 16:04:03 +0100

Watson Ladd schrieb am 01.03.2015 um 00:41:
>>>> 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 factually untrue: CMVP certified modules are permitted to
>>> implement other algorithms: they just can't be in FIPS mode when those
>>> 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.
> 
> 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.
> 

The question is how much assurance of security you get by running the HSM in non-FIPS-Mode. I know of a different vendor
of level 2 certified HSMs that use completely different firmware to support Brainpool curves. This practice makes it
more difficult for customers to accept the HSM running in non-FIPS mode to support Brainpool.

-- 
Johannes

---

From: Watson Ladd <[email-masked]>
Date: Mon, 2 Mar 2015 08:08:15 -0800

> more difficult for customers to accept the HSM running in non-FIPS mode to support Brainpool.

No assurance at all. You don't receive that from FIPS validation
either: the specified testing is geared towards correctness of
calculation rather than withstanding adversaries. But as I'm sure you
are aware, there are separate certification schemes for Brainpool
curves. Absent official communication from NIST, we don't know how our
choice will impact actions they may or may not take in the future.

Sincerely,
Watson

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

---

From: Paul Lambert <[email-masked]>
Date: Tue, 10 Mar 2015 14:37:37 -0700

Given that this illustrious Internet Research Task Group (IRTG) subcommittee, the Crypto Forum Research Group (CFRG), has a consensus to recommend the use of 'curve25519' for TLS, and given that NIST is soliciting input on elliptic curves it would be an opportune time for the Chairs of the CFRG to formally send the CFRG's draft recommendation (https://tools.ietf.org/html/draft-irtf-cfrg-curves-01) to NIST for the upcoming NIST Workshop on 'Elliptic Curve Standards' ( http://www.nist.gov/itl/csd/ct/ecc-workshop.cfm ).

     "NIST encourages presentations and reports
      on preliminary work that participants plan 
      to publish elsewhere."

Paul

PS - the deadline for submissions is March 15th

--
Workshop on Elliptic Curve Cryptography Standards
Purpose:

Elliptic curve cryptography will be critical to the adoption of strong cryptography as we migrate to higher security strengths. NIST has standardized elliptic curve cryptography for digital signature algorithms in FIPS 186 and for key establishment schemes in NIST Special Publication 800-56A. 

In FIPS 186-2, NIST recommended 15 elliptic curves of varying security levels for use in these elliptic curve cryptography standards. The provenance of the curves was not fully specified, leading to recent public concerns that there could be a hidden weakness in these curves. We remain confident in their security and are not aware of any significant attacks on the NIST curves when used as described in our standards and implemented correctly. 

However, more than 15 years has passed since these curves were developed, and the community now knows more about the security of elliptic curve cryptography and practical implementation issues. The current state-of-the-art has advanced. In research and other standards venues, newer curves have been proposed which pursue better performance or simpler and more secure implementations.

The workshop is to provide a venue to engage the crypto community, including academia, industry, and government users to discuss possible approaches to promote the adoption of secure, interoperable and efficient elliptic curve mechanisms.

Call for Papers (submission deadline March 15, 2015)

]-----Original Message-----
]From: Cfrg [mailto:[email-masked]] On Behalf Of Paul Hoffman
]Sent: Saturday, February 28, 2015 7:41 AM
]To: Peter Gutmann
]Cc: [email-masked]
]Subject: Re: [Cfrg] On "non-NIST"
]
]On Feb 28, 2015, at 12:59 AM, Peter Gutmann <[email-masked]>
]wrote:
]>
]> 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?
]
]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
]_______________________________________________
]Cfrg mailing list
][email-masked]
]http://www.irtf.org/mailman/listinfo/cfrg

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 10 Mar 2015 15:16:39 -0700

I am very curious about this as well. It would make for a very confusing
situation if NIST adopted different curves from the CFRG curves.

-- 
Tony Arcieri

---

From: Watson Ladd <[email-masked]>
Date: Tue, 10 Mar 2015 15:21:45 -0700

and Brainpool, and the French and Chinese governments, and the Russians,
and the Brazilians.

Standards fragmentation is a fact of life. But we should strive to minimize
it. And we shouldn't make it worse by varying endianess or encoding for
something that for 8 years was done a different way: there's no benefit to
doing it needlessly.

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

---

From: Paul Lambert <[email-masked]>
Date: Tue, 10 Mar 2015 15:27:40 -0700

> I am very curious about this as well. It would make for a very confusing situation if NIST adopted different curves from the CFRG curves.
Yes.  I assume that there will be individual advocates submitting curves to the NIST workshop proposing curve25519 and likely other curves.  Such individual presentations lack the strength of a group recommendation.

It would best for the industry to have a clear statement made by the CFRG Chairs of this research groups determination of consensus on the use of curve25519.  NIST does do a good job of documenting their recommendations and hopefully they will take curve25519 into their fold.

Paul

From: Tony Arcieri [mailto:[email-masked]]
Sent: Tuesday, March 10, 2015 3:17 PM
To: Paul Lambert
Cc: Igoe, Kevin M.; Alexey Melnikov; Paterson, Kenny; [email-masked]; [email-masked]
Subject: Re: [Cfrg] Submission of curve25519 to NIST from CFRG -> was RE: On "non-NIST"

I am very curious about this as well. It would make for a very confusing situation if NIST adopted different curves from the CFRG curves.

--
Tony Arcieri

---

From: Paul Lambert <[email-masked]>
Date: Tue, 10 Mar 2015 15:34:45 -0700

> Standards fragmentation is a fact of life. But we should strive to minimize it.
>And we shouldn't make it worse by varying endianess or encoding for
Could we please desist with the off-topic rants.  This was a request to the Chairs
to work more directly with NIST to propagate this task groups recommendations.
There was NO mention of endian! Such irrelevant points only add noise to
the mailing list.
>something that for 8 years was done a different way: there's no
>benefit to doing it needlessly.
Duh … and what about the 15+ years everyone else has setup the
bytes the other way round… (please do not answer on list, I don’t
care about the byte order today, my point is on irrelevant noise
and arguments).  If you wish to debate endian … start your
own new subject line.

Paul

From: Watson Ladd [mailto:[email-masked]]
Sent: Tuesday, March 10, 2015 3:22 PM
To: Tony Arcieri
Cc: [email-masked]; Paul Lambert; [email-masked]
Subject: Re: [Cfrg] Submission of curve25519 to NIST from CFRG -> was RE: On "non-NIST"

> I am very curious about this as well. It would make for a very confusing situation if NIST adopted different curves from the CFRG curves.

and Brainpool, and the French and Chinese governments, and the Russians, and the Brazilians.

Standards fragmentation is a fact of life. But we should strive to minimize it. And we shouldn't make it worse by varying endianess or encoding for something that for 8 years was done a different way: there's no benefit to doing it needlessly.

> [email-masked]<mailto:[email-masked]>

---

From: Watson Ladd <[email-masked]>
Date: Tue, 10 Mar 2015 16:19:58 -0700

> to work more directly with NIST to propagate this task groups
recommendations.

This group only has a recommendation of a curve right now. But that's not
enough: you need to specify what gets sent on the wire, and that's where
NIST potentially picks differently. So it's not enough to say use these
primes and these curves to NIST: that won't necessarily have the effect you
intend, precisely because that doesn't specify the coordinates and
encoding, even if they take our suggestion as opposed to others.

That's the worst possible outcome, especially if the names are the same.

> Cc:[email-masked]; Paul Lambert;[email-masked]
>
> > I am very curious about this as well. It would make for a very
confusing situation if NIST adopted different curves from the CFRG curves.
and the Brazilians.
>
> Standards fragmentation is a fact of life. But we should strive to
minimize it. And we shouldn't make it worse by varying endianess or
encoding for something that for 8 years was done a different way: there's
no benefit to doing it needlessly.

---

From: Paul Lambert <[email-masked]>
Date: Tue, 10 Mar 2015 18:14:47 -0700

It would be a mistake to delay an opportunity to send a recommendation from this
committee to NIST. Please note the quote:

      to publish elsewhere."
Your concerns about endianness are a trivial in comparison to the
overall industry change to new public key algorithms.  Please have some focus
and do not add noise to the topic.

The topic was a request to the Chairs to relay a position from this task group
to NIST before the March 15th deadline.

Paul

From: Watson Ladd [mailto:[email-masked]]
Sent: Tuesday, March 10, 2015 4:20 PM
To: Paul Lambert
Cc: [email-masked]; Tony Arcieri; [email-masked]
Subject: RE: [Cfrg] Submission of curve25519 to NIST from CFRG -> was RE: On "non-NIST"

> to work more directly with NIST to propagate this task groups recommendations.

This group only has a recommendation of a curve right now. But that's not enough: you need to specify what gets sent on the wire, and that's where NIST potentially picks differently. So it's not enough to say use these primes and these curves to NIST: that won't necessarily have the effect you intend, precisely because that doesn't specify the coordinates and encoding, even if they take our suggestion as opposed to others.

> From: Watson Ladd [mailto:[email-masked]<mailto:[email-masked]>]
> Cc:[email-masked]<mailto:[email-masked]>; Paul Lambert;[email-masked]<mailto:[email-masked]>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Mar 2015 22:42:25 -0400

On Tue, Mar 10, 2015 at 7:19 PM, Watson Ladd <[email-masked]> wrote:

> minimize it.
No, not really.

Converting from one private key format to another is routine. There is no
requirement for the key to be specified in the same endian order in the
cert and on the wire. It is not a topic that CFRG has a useful opinion on.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Mar 2015 20:11:10 -0700

Is there anyone from NIST still on this list? If so, can you please present an informal paper at the conference with an up-to-the-minute summary of the CFRG status at the time of the meeting? Extra points if you can do so without the terms "delay" and "bickering", of course.

--Paul Hoffman

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 11 Mar 2015 08:09:21 +0000

Hi,

dropping NIST from the CC for now.

>      on preliminary work that participants plan

The IRTF isn't really set up to send (or receive) formal liaisons to other standards bodies - but the IETF certainly is. So if the CFRG made their recommendation to the TLS WG, the TLS WG, Security Area Directors. or the IESG as a whole could send such a liaison.

Lars

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Mar 2015 10:06:06 +0000

Hiya,

On 11/03/15 08:09, Eggert, Lars wrote:
>> Given that this illustrious Internet Research Task Group (IRTG) 
>> subcommittee, the Crypto Forum Research Group (CFRG), has a 
>> consensus to recommend the use of 'curve25519' for TLS, and
>> given that NIST is soliciting input on elliptic curves it would
>> be an opportune time for the Chairs of the CFRG to formally send
>> the CFRG's draft recommendation 
>> (https://tools.ietf.org/html/draft-irtf-cfrg-curves-01) to NIST
>> for the upcoming NIST Workshop on 'Elliptic Curve Standards' ( 
>> http://www.nist.gov/itl/csd/ct/ecc-workshop.cfm ).
>> 
>> "NIST encourages presentations and reports on preliminary work
>> that participants plan to publish elsewhere."
> 
> The IRTF isn't really set up to send (or receive) formal liaisons
> to other standards bodies - but the IETF certainly is. So if the
> CFRG made their recommendation to the TLS WG, the TLS WG, Security
> Area Directors. or the IESG as a whole could send such a liaison.

We can liaise sure. I chatted with Kenny about this before and I
think the plan was for the CFRG chairs (or one of 'em) to submit
a short position paper on what's being done in CFRG. I think that
would be better than a liaison.

But if that's not going to happen we can certainly liaise. So
CFRG chairs - will you get around to that this week or have you
done it already?

Cheers,
S.

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

---

From: Michael Hamburg <[email-masked]>
Date: Fri, 13 Mar 2015 11:49:24 -0700

I have submitted Goldilocks to this workshop, and if it is accepted I can present general IRTF EC choices alongside it.

— Mike

> On Mar 11, 2015, at 3:06 AM, Stephen Farrell <[email-masked]> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Hiya,
> 
>> [email-masked] <mailto:[email-masked]> http://www.irtf.org/mailman/listinfo/cfrg <http://www.irtf.org/mailman/listinfo/cfrg>
>> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJVABOKAAoJEC88hzaAX42ievwH/0mhNjJCsCglov5FSu3f+3jx
> mHJ88aHtyTZT2fFwGuY9iFCQztrt1MTtbCli2mJxErz3B1rICOBip63IirrQ1k8s
> XkKKRHefIHY+aIk3A6jhtQ8I64gX+MaHmX5IdFVO6MK6TVMrQv5D0rL6toe0Rnoy
> rVV/X6B7M+bwHR9Yf4/C8HeFIGYtJAc/XctI0qg0Py658JEzwxaE40y87B0dmd25
> nxPDDBoAf3vN488rrk3jah+tFzi+drTSdI6QYvq9TuAdNJDeBwvBBGl34jxf4faV
> ZMC2iXyiDyIS2zq9knODtkv/Mcn5Ujr9J5O/8Jlh4SeZZN2cXe98G1zt+J+nI+E=
> =2PEU
> -----END PGP SIGNATURE-----
> 
> [email-masked] <mailto:[email-masked]>
> http://www.irtf.org/mailman/listinfo/cfrg <http://www.irtf.org/mailman/listinfo/cfrg>