Subject: Re: [saag] possible BCP on public review being needed for standards-track crypto

From: Jon Callas <[email-masked]>
Date: Tue, 5 Apr 2016 21:50:25 -0700

Steven, Rich,

I read through the possible draft on standards-track crypto and I have mixed feelings about it. 

On the one hand, how could anyone be against it? What it proposes is like motherhood and apple pie. It almost goes without saying that we shouldn't use bad crypto in mandatory-to-implement (MTI) on standards track.

On the other hand, I remember a bit of advice from Jeff Schiller back in the day, that the purpose of a standard is interoperability. Standards exist so that I can decode a protocol to know what it means, and to encode it so someone else can do the same. While, of course, one can take this principle to excess, it's an important one to remember.

Thus, one has to figure out just the right path for a BCP that it hits the right notes. I recognize that in looking at this draft, I have to fill in a lot in my head and see where you're going with it. So I apologize if I misinterpret anything.

What constitutes "public review" is a thorny issue, and one that revolves around. I'm glad that the document admits that this is a thorny issue, but it's really a lynchpin of the idea. We can have a vague definition -- even "I know it when I see it" is fine, but it's not clear that it adds anything to the existing IETF processes. We're still going to hum.

Another core issue is whether it refers to MTI crypto only, or if it's supposed to be broader. I hope that the answer is that of course it's only applies to MTI and not optional-to-implement (OTI), because if it's saying MTI but means OTI, then that's a problem with the document structure -- at the very least, a BCP ought to say what it means.

An issue that I see with this from a very high level is the possibility that it could produce the opposite effect that is intended. That is, that it would provide *cover* for bad crypto to resist being replace.

Let's look at a slightly hypothetical scenario where someone has put DUAL_EC_DRBG into an IETF standard (or one about to become one) so as to cover any possible errors in the host operating system's random number generator. Quickly, we'll say that the standard says that the protocol should seed DUAL_EC_DRBG as a whitening function. We'll also presume there's no malice here, only something that will look stupid in the future as it is a flaw that ruins the whole protocol. Let us also assume that this discussion is *after* the CRYPTO Rump Session talk noting that you can't show it to be secure, but before we get consensus that it isn't secure.

How would you use this BCP to help challenge this use? DUAL_EC_DRBG *is* peer-reviewed. It's a NIST standard, part of ANSI X9, part of NSA Suite B, and so on. The problem in this case is that the peers have made a mistake that will become apparent later. It is also a mistake that looks and sounds paranoid and conspiracy-theory until the Snowden documents show otherwise.

I have the concern that implicit in the goal of this BCP, to somehow argue for "good crypto" is hindered by the BCP as it's presently going. It would be better not to have a BCP than to have one that supports bad crypto that has peer review. Phrased another way, this BCP assumes that peer review is a proxy for goodness, but I believe that it fails in one of its main examples.

There are some other examples that I think are side-points, or get to the MTI/OTI issue.

If we look at the history of A5/*, the GSMA picked those a long time ago with a different set of goals, and those goals included the compute power available, as well as the legal environment of the day. I'm hardly suggesting A5/* as anything worth doing, but I don't see how it's an example here of anything relevant to the IETF in specific because it's such a period piece and an example of how a closed standards body did something we disagree with.

The WEP/WPA examples are interesting, and this is a place that Russ Houseley can help with. He's given some *very* interesting talks on how we got into the WEP mess, and how WPA led the way out. It's interesting because it is a standards failure, and because it moved in fits and starts and with a set of goals that included having to be field-replaceable. I think it has a place here, but like DUAL_EC_DRBG, WEP used peer-reviewed crypto. I have to ask how this BCP could help prevent or *replace* WEP or prevent it, as opposed to propping it up or preventing it in the first place.

Patented crypto in general is something I don't worry about, and I think can be handled on the basis of intellectual property concerns. In general, I don't worry about it. If we look at the history of ECC, back in the days when it was kinda dodgy, it was also constrained by patents. It's possible that fewer patents would have hurried research, but I think we benefitted by giving ECC a few places to have its own sandbox, but largely dealing with it as a new technology *because* it had patents restricting it. The first generation of public key systems are an exception, really.

This gets back to the idea that standards are for interoperability. I really care about being *forced* to use things that are new or encumbered, but traditionally the IETF has supported a community of interest that wants to standardize some protocol for their own uses. I think this is also a good thing. Let the new things win in the marketplace of ideas. We should be very, very careful to make it so that it really is crazy talk that the IETF is a cabal with its own agenda.

Traditionally, the IETF has supported things that have a community of interest but people might not like the security of. For example, there are documents for IBE systems, and while I'm not at all a fan of IBE (because they're all implicitly key escrow systems), they have uses in closed communities or people who need or want them. I don't have a problem with RFC 5091, 5408, 5409, 6508, 6509, 6539, or any of the others, as long as I don't *have* to use them. It's OTI as opposed to MTI. Let people have all sorts of stuff as OTI, and as a standards body we just make sure it doesn't sneak into being MTI. Perhaps we don't want a thousand flowers blooming, but a dozen or two is a good thing, and let time settle it out.

This gets me to my big raised eyebrow, the example of Algebraic Eraser. The cryptographic merits of Algebraic Eraser are complex. Personally, as a cryptographer, I put it into the same bin of things that are useful in places just not everywhere. IBE is also in that bin. For me, GCM is in that bin. "Lightweight" crypto and things like Speck (which is in the document name, but not yet mentioned in the document) are in there for me, too.

What is relevant to this BCP, is that the Algebraic Eraser people have never asked to be MTI crypto, and yet this document seems to be suggesting that they shouldn't be allowed to be OTI. Initially, as I was first writing this set of comments, I kinda brushed it off and suggested that you just drop it. But the other discussion of late makes me think that this is somehow *directed* towards Algebraic Eraser, that part of its point is to stop it from being in documents. It is the *only* controversial algorithm mentioned. The document mentions A5/*, DUAL_EC_DRBG, RC4 obliquely through WEP/WPA, and an algorithm that only wants to be an OTI algorithm. 

I could ask why, but it's just easier to say that mentioning it all makes it look like this BCP has an agenda that is not its stated goal, so it's best that that be deleted. It makes it look like this is using MTI restrictions as a rationale for OTI restrictions, which I'm sure is not its intent. Let's just move on.

So to summarize, I think there are major structural things this document needs:

(1) Attention to making sure it doesn't become that which it is opposed to. It needs a document philosophy security review. It needs to look at how it could have prevented problems in the past. It needs to red-team itself and look at scenarios like how well it defends DUAL_EC_DRBG against the doubts that Shumow and Ferguson bring up.

(2) The document needs to make its case within the context of the IETF. The example of A5 in the GSMA isn't relevant because the IETF is not the GSMA. The WEP/WPA case is less orthogonal, but you'd need to say that this BCP, if only used over there with people who have similar goals, could have avoided it. All the examples you have at present are mistakes others have made.

(3) The document needs to look at traditional goals of the IETF itself, particularly with the MTI/OTI separation. It is a *strength* of the IETF that it permits standardization as interoperability, as opposed to being a quality gate. It is a *strength* of the IETF that it permits communities of interest that use new and innovative technology. That it is not the crypto equivalent of L'Académie française, that it lets a few flowers bloom and fend for themselves. If the IETF loses that, then it loses what makes it valuable.

At the end of everything, I think the challenge is to turn the basic idea that no one could possibly disagree with into something useful, actionable, and a step forward.

	Jon