[Cfrg] process for cfrg blessing of [insert algorithm name here]

[Sean Turner <[e-mail]>]

I’d like to get to the thread that I think Waton/David are after [0]/[1].

I’ve got a hat but I’m not wearing it here (and my hat goes away in two months anyway).  I guess I’d like to add that I’m not a cryptographer, but I don’t know why I need to say that because it’s not like anybody has to take a test to contribute to the CFRG.  And anyway you’d figure it out right quick when I responded “do I get an egg roll with that” when quizzed about the Chinese remainder theorem.  (it’s a long email I thought I’d lead with a joke)

Because the "IRTF does not set standards” [2], remember there are RFCs that are on standards track and some not [3], it kind of follows that the “The Research Group input carries no more weight than other community input” [2].  But, I kind of find it hard to believe that if the CFRG publishes "[insert cryptographic algorithm's name] is rubbish” that the IETF would produce a standard around said algorithm.  On the flip side, just because the CFRG publishes "[insert cryptographic algorithm's name] is fabulous” I wouldn't expect every IETF WG to fall over themselves changing their MTI (Mandatory To Implement) algorithm.

The current practice that the Security ADs have been using is here [4], which resulted from input from the IETF community as a result of push back from implementers on what I called “crypto proliferation". (yes the email referenced says TLS but that’s because folks with algorithms want to do that one first as most bang for buck and then move on to other WGs)  You’ll note the CFRG isn’t listed there and I don’t think I’d require it be there, but what’s not documented there is what happens before authors go for code points.  Before authors are going to get a code point, they need to document their algorithm (in English) someplace.  A lot of times that’s ended up being an internet-draft that goes through the ISE process and gets published as an Informational RFC; examples include: GOST [5], Camellia [6], SEED [7], ARIA [8], Rabbit [9], Brainpool [10], CLEFIA [11], and Kcipher-2 [12].  To get through the ISE process they need to show some kind of review, here’s where everybody says go to the CFRG and see what they say they’re the cryptographers.  To be honest most of the time it’s pretty quiet.  Maybe that’s to do with the fact that many of the requests for review are for national algorithms.

In any event, I think we should consider the following (there might be more):

0) Should we move the CFRG to the IETF?
1) Should the CFRG be more proactive?
2) How does a new cryptographic algorithm get through the “process”?

I use the term process her pretty loosely but it’ll address the CFRG impact on IETF adoption of cryptography.

Here’s what I think:

0) Should we move the CFRG to the IETF?

I say no for a couple of reasons:

a) I think it’s not necessary unless we’re going to start standardizing cryptographic algorithms.   I don’t think the IETF has ever published a cryptographic algorithm on standards track (more examples include [13][14][15][16]) instead what’s done is a standards track RFC that documents the "use of cryptographic algorithm x in protocol y” (e.g., [17][18][19]).  (yes there was one BCP that deprecate the use of well-known weak algorithms [20]).  I think many of the successes of the IETF actually come from protocols that were partially developed outside of the process and then finished off (for some value of finished off) and I suspect the same will be true of any cryptographic algorithm published by the IRTF or through the individual stream (more on this distinction later).

b) I can’t see having a WG or RG that has the “power” to enforce “cryptogoodness”.  It would be perceived as a hammer with which to beat up draft authors, wg chains, and other ADs and if you’re following the thread on the IETF discuss list about Stephen’s perpass-attack draft you’ll note that seems to be a fear shared by more than a couple of people.  Rechartering to enforce “cryptogoodness”, I bet, will no doubt be challenging and I’d submit an unnecessary waste of time.

c) I really think the CFRG should look out past the IETF's time horizon.  You’ll note the word “new” in the CFRG’s charter and from what I’ve seen adopting “new” crypto is not really done it’s usually got to marinate for a while.  So having something we’d been thinking about for a while to replace say RC4 would have been well nice.  Now some of this is water under the bridge but maybe we should be thinking two steps ahead to the next curve beyond say 25519, cha cha, etc.  I’d be cool if we actually did stuff like provide a venue for folks to exchange test vectors etc when developing (preferably) open source crypto.

1) Should the CFRG be more proactive?

I know what the fox says [21]: Hell yeah!

There's *nothing, nada, zilch, null, zéro, صفر, 零* stopping anybody from writing an individual draft and then asking for it to be adopted by the RG.

     Chairs: Do you prefer RG adoption emails come from
     you (initiated by authors) or a more free-for-all approach
     when authors ask that it be adopted from the RG?

I wanted to put the final IETF nail in the coffin for MD2, MD4, and MD5 (certain uses) [22][23][24] and got some input from CFRG  participants.  If there’s more like this that need to be done, just do ‘em and then we can use it them to deter folks from making bad choices.

If you’re really keen, then I’d also like to suggest that you volunteer with the ISE (Independent Stream Editor) to help review the cryptographic protocols that come through their stream.  There’s a couple on call, but more would certainly be welcome.  Mail to: [e-mail].

2) How does a new cryptographic algorithm get through the “process”?

I think it kind of depends on the definition of “new” is, the type of algorithm, the type of registry from which you’re requesting a code point [25], and what the WG requires.  Let’s explore some of these:

Based on what happened in the past, should the CFRG and not the ISE be the stream where algorithms get published?  For those not in the know, the stream dictates what kind of review the draft gets and what “kind” of RFC can pop out at the end.

I suspect that authors care little about the stream.  They just want to get published.  If the algorithm:

a) Is a national algorithm - I’ve no doubt it’ll get reviewed like every draft progressing through the process and possibly even some errors will be uncovered (it’s happened).  Somebody who works for the newly formed national gov't of Bitcoinlandia shows up with Cesar's Cipher - would “Bitcoinlandia’s Ceasar’s Cipher” be blocked from publication?  I suspect that it wouldn’t as long as it was clear that it was a national algorithm or one of a suite of national algorithms.  In any event, if changes were offered and not accepted I’m thinking the ISE is likely to let it go probably based on the grounds that the changes would make the published RFC differ from the already published national standard.  Would the CFRG do something different?

b) Has properly marinated over time and not been shown to have weakened considerably and there was a security proof - I suspect that the grilling would be procedural in that the authors would just need to have the intestinal fortitude to make it through the process.  I guess the same question from a applies though.

c) Is like b but it doesn’t have a security proof - If an author brings a draft to the CFRG is progression through the IRTF going to require one?  If the an author goes to the ISE is the CFRG going to block progression based on a lack of security proof?

d) Is “new” with no security proof - I’ve no doubt it’d get raked over the coals (i.e., given rough treatment), but … I guess the 800lbs Gorilla is on what grounds is it okay to stop a draft in its tracks?

- How long must crypto marinate?

- If it’s similar to something that’s already available should it be stopped?  Maybe the existing algorithm won’t work for whatever reason or the consumers (I’m assuming there is somebody who wants to use it it’s not just about getting an RFC published) are somehow sold on the “new” way.

- If there’s no security proof, then how does an author get one (wait, pay, beg)?  Seriously: I know some cryptographers but they have day jobs and I know some researchers but I think they’re maybe more motivated by publishing a new attack on a well-known and widely deployed protocol am I just supposed to know my role and not try to develop a cryptographic protocol.

- What if the authors are actually engaging and making changes but there is a point at which there is an impasse - can they document the known vulnerability/weakness in the security considerations and move on?  

There are also registries that only require expert review and there is no requirement for them to consult with the CFRG on the goodness of algorithms before choosing to give a code point.  I can’t think of a time when this happened and I’m pretty sure an expert wouldn’t do that, but I'm also unsure whether the process would be changed to give the CFRG veto power.

After getting here and re-reading what I wrote it all sounds like doom and gloom but remember what the fox said!

spt

[0] http://www.ietf.org/mail-archive/web/cfrg/current/msg03595.html
[1] http://www.ietf.org/mail-archive/web/cfrg/current/msg03685.html
[2] https://datatracker.ietf.org/doc/rfc2014/
[3] https://datatracker.ietf.org/doc/rfc2026/
[4] http://www.ietf.org/mail-archive/web/tls/current/msg06470.html
[5] GOST:
https://datatracker.ietf.org/doc/rfc5830/
https://datatracker.ietf.org/doc/rfc5831/
https://datatracker.ietf.org/doc/rfc5832/
[6] Camellia
https://datatracker.ietf.org/doc/rfc3713/
https://datatracker.ietf.org/doc/rfc5528/
[7] SEED
https://datatracker.ietf.org/doc/rfc4269/
[8] ARIA
https://datatracker.ietf.org/doc/rfc5794/
[9] Rabbit
https://datatracker.ietf.org/doc/rfc4503/
[10] Brainpool
https://datatracker.ietf.org/doc/rfc5639/
[11] CLEIFA
https://datatracker.ietf.org/doc/rfc6114/
[12] Kcipher-2
https://datatracker.ietf.org/doc/rfc7008/
[13] https://datatracker.ietf.org/doc/rfc2104/
[14] https://datatracker.ietf.org/doc/rfc3394/ 
[15] https://datatracker.ietf.org/doc/rfc3447/
[16] https://datatracker.ietf.org/doc/rfc3610/
[17] https://datatracker.ietf.org/doc/rfc4056/ 
[18] https://datatracker.ietf.org/doc/rfc6655/
[19] https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp/
[20] https://datatracker.ietf.org/doc/rfc6649/ 
[21] http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCsQtwIwAA&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DjofNR_WkoCE&ei=5q_EUsv0MbSqsAT1-oDYDQ&usg=AFQjCNE9-Z1oW5gVjc6rJg_-KAhmjY_Qfg&bvm=bv.58187178,d.cWc
[22] https://datatracker.ietf.org/doc/rfc6149/
[23] https://datatracker.ietf.org/doc/rfc6150/
[24] https://datatracker.ietf.org/doc/rfc6151/
[25] https://datatracker.ietf.org/doc/rfc5226/ and updates
(actually check out https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/)