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

On Wed, Jan 8, 2014 at 12:16 AM, Sean Turner <TurnerS@ieca.com> wrote:
> I’d like to get to the thread that I think Waton/David are after [0]/[1].

Thank you very much for writing the email that I wanted to have
written, but wasn't able to write.

>
> 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.

I think this is unduly optimistic about the ability of IETF WGs to vet
their use of cryptography. The TLS WG has a long and ignominious
history of failure in the form of unforced errors, and that is merely
the most visible and researched one. These mistakes mostly aren't
algorithmic, but rather
how the algorithms fit together to form a protocol.

>
> 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.

Do you think that if someone had beaten the TLS 1.0 authors over the
head about EtM vs MtE, that this would have been a bad thing? The
issue of the disconnect between what an engineer knows about crypto
and what they need to know about crypto is very far reaching: every
single WG that considers a cryptographic protocol faces it. The best
way I think to handle this is provide a central resource to ask: "hey,
we are doing X, is it a good idea?" and tell people they should
seriously consider it. That means having a very fast process, and
having a reputation for giving good answers.

>
> 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.

How many implementations does the world need?

Once again the distinction between primitives and protocols comes
back. A new block cipher definitely needs to marinate: we don't have a
comprehensive idea of what could be possible. But a new ECC parameter
set can be validated in a few minutes with GP/PARI: compute certain
invariants, and see that they avoid known bad choices. A new key
agreement protocol should require a solid proof and automatic
verification.
The process we follow needs to take this into account.

Post-Quantum Crypto is something we will need, and is going to need a
lot of development. NTRU is I think mature from a design perspective,
but patented, while McBits involves giant keys. (Not necessarily that
bad). The situation with post-quantum signatures is annoying: we have
Merkel signatures, but HFE variants are nicer to use, but a lot have
fallen, or it's unclear what parameters are needed. Anyway, we have
some urgent issues to deal with first.

>
> 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: rfc-ise@rfc-editor.org.
>
> 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.

As an author, how do I determine what streams my drafts are going
into, and how do I push them to active consideration?
A lot of good crypto drafts sit around in limbo: I'm sure this is true
for all drafts, but for some of the crypto ones it's causing
actively exploited problems to linger unfixed for years.

>
> 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.

I think if the already available protocol has stronger security
properties, and there isn't a compelling need for the new one, than we
should avoid giving people the choice.

>
> - 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.

The way you do this is by looking in IACR for an eprint solving your
problem, and adapt that to your situation. I've never seen or heard of
an IETF protocol requiring a new primitive. If you are not a
cryptographer, you shouldn't be doing cryptography, any more than
someone who isn't a structural engineer should design a bridge. And
just as most bridges can be ordered from a catalogue, most protocols
don't require new crypto.

>
> - 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?

No. There is never a compelling reason to approve or use an algorithm
with a known weakness when a better one is available. If there is a
new
need that existing algorithms don't fill, then an effort should be
made to fill it with the best algorithm possible.

>
> 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.

Depends on who the expert is. If you ask DJB or Tanja Lange about an
elliptic curve, you are asking the right people. Ask Knudsen about
block
ciphers. But if you ask Knudsen about curves, or DJB about block
ciphers, they won't know much more than you do. The best solution is
to have a
body of people, maybe a "Crypto Forum Group" who when asked can find
out what is known and document it.
>
> 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/)
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin