Subject: [Cfrg] FIPS or equivalent approvals

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 29 Jul 2014 11:03:19 -0400

Choosing a curve is not all that we are going to need to make ECC crypto happen.

If we are going to use the new curves in PKIX (a major part of TLS) we
are going to need trustworthy HSMs. Which in turn means that we are
going to need some standard for approvals to be audited against and
possibly someone to run the process.

This might well mean that it is impractical to move away from some
form of DSA for signatures or at the very least mean that there is a
penalty for doing so. This is not likely to be as urgent a concern for
encryption as that is only an end entity issue and only a tiny
proportion of end entity applications require approved HSMs and those
that do are likely to require the NIST curves anyway.

So one consequence of this is that it would probably be advantageous
to the hardware vendors if they started taking notice of the
discussions as they are likely to see demand for new HSMs in the near
future.

Getting their participation and input would probably be useful to all concerned.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Jul 2014 08:34:31 -0700

> possibly someone to run the process.

What do you mean by "we" in that paragraph? CFRG does not need HSMs, and CFRG does not ned "some standard" for anything. I suspect you mean "implementers of IETF standards", which is not "we".

CFRG should do research and make recommendations for new cryptography to the IETF regardless of what it might cost for implementers to use what is proposed.

--Paul Hoffman

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 29 Jul 2014 11:45:49 -0400

> If we are going to use the new curves in PKIX (a major part of TLS) we are
> going to need trustworthy HSMs.

I disagree with the idea that PKIX is a major part of TLS, the implication that RSA 2K certs need to be replaced quickly, and that HSM's are needed by the CA's.

Other then that, the sentence is fine. :)

	/r$

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 29 Jul 2014 13:37:32 -0400

> CFRG should do research and make recommendations for new cryptography to the IETF regardless of what it might cost for implementers to use what is proposed.

In large measure I agree with Paul, to some definition of cost.

Cloud computing (for example) clouds the whole HSM discussion and really 
scares the bejeepers out of me (based on discussions I have had with 
cloud/nfv/onf people on this subject).

So let's keep our battlefields clearly delineated and not have one 
campaign spill over into another.

---

From: Alyssa Rowan <[email-masked]>
Date: Tue, 29 Jul 2014 18:59:53 +0100

On 29/07/2014 16:03, Phillip Hallam-Baker wrote:

> trustworthy HSMs

A mammoth problem, and not one I believe CFRG is really in a position
to solve.

Given EDGEHILL and BULLRUN and related concerns about the CESG/FIPS
validation processes, I feel a HSM/smartcard/token design actually
worthy of third-party trust would need:

• Open, transparent, public open-source design, from software down as
  far as practical - right down past the mask to the gate/process level
  if possible;

• To be publicly and independently tested, verified and verifiable;

• To be practically immune to all known or reasonably speculated
  attacks

No current vendor or product meets - or even comes close to meeting -
those criteria, as far as I am aware. [And if you think one does, or
intends to try, please let me know, as it is an area of interest!]

Since you'd be looking at a clean-slate design with a completely
different (dramatically open, nothing-up-my-sleeves) approach compared
to the (closed, black-box, relatively analysis-hostile) status quo of
current commercial crypto hardware, I see no good reason to be chained
to any particular legacy algorithm at all - let alone (EC)DSA.

In fact, I'd be tempted to suggest that one good approach might be to
make a (very) special-purpose, cut-down open-source CPU, with
verifiable design, well-defended (constant time & power; cacheless?
parity? Microcode-free?), and particularly good at the kind of
operations often used in crypto, pair it with a well-vetted NDRNG, and
then to write verifiable software for that base implementing the
actual algorithms. Minimises the trust base; maximises flexibility;
possibly could extend service life of the design. But I'm not sure it
falls within scope of this group.

Links which might be of some interest:
• https://cryptech.is/ - directly relevant; an attempt to do this
• https://sel4.systems/ - tangentially relevant; now open-source!
• http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ - perhaps
  irrelevant exactly, but I found it interesting research anyway

- -- 
/akr

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 29 Jul 2014 14:16:27 -0400

> Other then that, the sentence is fine. :)

That depends on your definition of 'quickly'. I don't intend to do
this according to the 'waterfall' development model where anyone who
looks ahead more than one problem at a time gets told to wait for what
turns out to be three years for a decision. We have seen the result of
that approach in IPv6 and DNSSEC.

If this group wants to make the decision it is going to have to allow
for parallel processing of things that can be done in parallel. It
will take a little while for the hardware folk to take notice. And
some of those vendors have expertise that I think is rather useful,
they have been facing issues such as side channels for a long time.

Given that this is essentially a bikeshedding decision process, one of
the criteria is going to be which curve's supporters is willing to do
most to persuade people that they will win.

As for CAs not needing HSMs, I don't think any of the browser
providers is going to accept a root that is not protected by some
FIPS-140 equivalent validated HSM with multiple separation of duties
controls.

We will need the whole industry on board in the end. At least in
nCipher, Aladdin, Intel, AMD, ARM etc are asked early on they won't
have an excuse to complain later.

Making the approach is a signal to their people to think about
planning to put some of this stuff on their roadmaps.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 29 Jul 2014 14:24:12 -0400

On Tue, Jul 29, 2014 at 1:59 PM, Alyssa Rowan <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>

It isn't just the US up to these things.

Before the PRISM disclosures I spent a lot of time with some people
whose names would be familiar looking at the problem of stopping them
doing unto the US what we now know they were doing unto others
(including US companies).

Supply chain is a hard problem. But not being able to guarantee that
the crypto has not been bongoed by Fort Meade does not mean that I
want to accept the risk of being able to extract a valuable root key.
That would be a major personal safety risk.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 29 Jul 2014 14:43:06 -0400

> I feel a HSM/smartcard/token design actually worthy of
> third-party trust would need:

Check out http://cryptech.is

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: [email-masked] Twitter: RichSalz

---

From: David Jacobson <[email-masked]>
Date: Wed, 30 Jul 2014 20:54:45 -0700

> Check out http://cryptech.is
In a past life, I worked on the design of an HSM that was used by lots 
of banks.  (FIPS 140-2 level 3)   It was basically just an ARM processor 
and a crypto accelerator in a module coated with hard opaque epoxy.  
There is no reason that the firmware couldn't be modified to do Curve 
25519.  Of course, it would be slower, since it wouldn't get any benefit 
from the crypto accelerator, and you couldn't put it in FIPS mode with 
that curve enabled (not a "FIPS approved algorithm").

     --David Jacobson

---

From: David Jacobson <[email-masked]>
Date: Wed, 30 Jul 2014 21:50:43 -0700

On 7/30/14 8:54 PM, David Jacobson wrote:
> of banks.  (FIPS 140-2 level 3)   It was basically just an ARM 
> processor and a crypto accelerator in a module coated with hard opaque 
> epoxy.  There is no reason that the firmware couldn't be modified to 
> do Curve 25519.  Of course, it would be slower, since it wouldn't get 
> any benefit from the crypto accelerator, and you couldn't put it in 
> FIPS mode with that curve enabled (not a "FIPS approved algorithm").
>
>     --David Jacobson
Oops.  I replied to the wrong message.  There was a talk of how a new 
curve would require new HSMs, and the manufacturers should get working 
on it, etc.  My point was that for the manufacturer who has all the code 
for the HSM, adding a new curve is is much simpler than designing an HSM 
from scratch.   Rich's remark was about the need for an open HSM, so we 
could trust it.  An entirely different subject.

    --David

---

From: Randy Bush <[email-masked]>
Date: Thu, 31 Jul 2014 10:38:17 +0200

> 25519.  Of course, it would be slower, since it wouldn't get any
> benefit from the crypto accelerator, and you couldn't put it in FIPS
> mode with that curve enabled (not a "FIPS approved algorithm").

the first iteration of the cryptech project has an fpga base, and dr
lange has offered 25519 verilog.  as the design is attempting
[de-]composability, one could leave 25519 out if going for fips
approval.  efficient, constant time/power, so what's not to like?

randy<