Subject: [saag] Cryptographic Algorithm Suite Conformance Criteria

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Mar 2014 10:42:31 -0400

Following the discussion at SECDIR, I have written a draft describing
consensus choices of cryptographic algorithms.

http://www.ietf.org/id/draft-hallambaker-consensuscrypto-00.txt

Rationale:

At present each IETF WG specifies Mandatory to Implement crypto algorithm
suite choices individually. This approach is unsatisfactory for the
following reasons:

* The objective of an IETF WG is to shut down having completed its work. So
there is no WG to arrive at consensus that an update of crypto algorithms
is required.

* Different WGs are chartered at different times and the choice of
mandatory to implement algorithms tends to vary according to what the
community believed to be the case when the documents were published rather
than what is considered to be best current practice.

* There is an industry trend towards adoption of Elliptic Curve approaches
'at some date in the future'. The choice of crypto should be taken by the
security area and crypto community as a whole rather than individually for
each protocol.

* Security does not come from offering or even using more secure
algorithms. Security comes from stopping use of weak algorithms or
no-security. We don't currently have a good way to declare compliance with
a decision to declare an algorithm obsolete.

The objective of this draft is to have something that can be quoted in an
RFP or product brochure, RFC-7??? compliant means that it supports this
crypto set. If we make RFC7??? obsolete then implementations can't claim to
be current.

The objective here is to follow consensus, not lead it. So if there is not
consensus on a choice I leave it blank. At the moment IETF specs only
specify Mandatory to Implement as a rule. There are some earlier specs that
required algorithms that are now defunct and recommended the current
consensus algs as backup.

I am aware that crypto is not exactly plug-and-play. And the documents
deliberately avoid issues such as choice of block cipher modes for that
reason. As a rule, I don't expect that an algorithm is likely to be
considered a consensus choice as Required or Recommended unless there was a
document specifying how to apply it in the principle IETF security specs
where this is likely to be an issue (IPSEC, TLS, S/MIME, PKIX, OpenPGP,
SSH).

I am also aware that we now have something of a mess surrounding the choice
of EC curves due to Snowdonia. However that might actually accelerate
deployment since it may well bring the choice of algorithms and curves to a
head.

The document specifies a set of Required algorithms which is the usual
suspects (SHA-2-256, AES-128, HMAC-SHA256, DH, RSA). There is also a set of
Recommended algorithms that is intended to serve as backups.

If we care about algorithm agility we should at minimum indicate a best
guess for what the replacement algorithms should be.

One of the secondary purposes of this exercise is to try to get some
discussion going as to what our next generation cipher suite should look
like and provide a nucleus around which consensus could emerge.

I don't think we necessarily can or should come to consensus on replacement
public key algorithms for Version 1 but we can probably do that by version
2.

That leaves one major hole in the current draft, there is no backup
encryption algorithm. This came up in hallway discussions at STRINT. We
could certainly just pick one. But the AES competition was started in 1997,
that is getting on for two decades ago. There seemed to be feeling that we
are about due for another, although this time we should probably look to
sponsorship from outside the US government for a change. The process in
which the participants in the process were the ones to vote certainly gave
it a lot of credibility.

-- 
Website: http://hallambaker.com/