Re: [Cfrg] how can CFRG improve cryptography in the Internet?

[Daniel Kahn Gillmor <[e-mail]>]

On 02/07/2014 02:04 PM, David McGrew wrote:
> An approach that might work for us is to develop replacement mechanisms
> for the ones in current use that we think need to be replaced, keeping
> in mind that the actual replacement might take ten years or so, or might
> never happen.   At the same time, we can document the problems with
> existing mechanisms, to help provide a motivation for that replacement.

beyond figuring out how to deprecate currently-bad crypto, i think it
would also be a worthwhile exercise to think about how to design
*deprecatable* crypto mechanisms and protocols.

Our current state-of-the-art for cryptographic agility is that we build
ways for systems to tack on newer and better features.  The trouble is
that we don't have a way to systematically deprecate older/known-bad
features.

I don't know if this specifically in-scope for the CFRG, but i would be
very happy to see some best-practices advice that suggests a way to
ensure that the cryptographic mechanisms we deploy have a clear way to
deprecate them when known attacks and vulnerabilities surface.

One way of thinking about this is the idea of revocation, but algorithm
revocation instead of certificate revocation.  This is troubling,
though, because we are currently terrible at certificate revocation :(

Another approach could be to design cryptographic software with built-in
expiration dates for *every* algorithm.  The software could check the
current date, and would know when a given algorithm was due to expire,
and warn the user that their communications security is in doubt if they
are using an expired algorithm (or refuse to use the expired algorithm).
 Software updates could either (a) deploy new algorithms with later
expiration dates, or (b) indicate that we have more confidence in an
existing algorithm, thereby extending its current expiration date.

Having this built in from the beginning means that we would at least
have a time-limited window to re-validate algorithms, and service
operators could remove expired mechanisms with confidence.  It would
also mean that devices need to be able to update their software, or
their algorithm definitions and expiration dates as well (it would not
work for clockless or non-networked devices or devices without any way
to signal to the user that the algorithm is expired).

Anyone interested in discussing sane and safe ways to pro-actively plan
for secure and sane algorithm or protocol deprecation?  Can we deem this
in-scope for the CFRG, or are there other places where the discussion
might be better placed?

> At the same time, I share the frustration that too much bad cryptography
> is in use, which should have been replaced long ago. The fact that it
> might take years to replace is no excuse not to start the process now.  
> I'm thinking of RADIUS and other protocols that are used with
> human-generated passwords (and are not PAKE systems) in particular.   It
> would be *great* to have CFRG document what protocols are bad, and how
> bad they are, in a way that we could demonstrate expert consensus on our
> opinions. If we did a decent job, I bet we could get a slot in front of
> the IESG or some other responsible IETF group.   I am confident that, if
> we can offer IETF good information about the security of current
> standards, they will find a way to propagate and use that information.

I also think formally and explicitly deprecating known-bad approaches is
good.  RFC 6176 is an excellent and useful document.  However, i remain
surprised that we haven't made such a statement about cleartext(!) -- if
we believe that pervasive surveillance is an attack on the internet, a
strong and explicit RFC stating cleartext communication on the 'net is a
Bad Thing could be comparably useful.

	--dkg