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

Sean Turner <TurnerS@ieca.com> Sun, 12 January 2014 21:25 UTC

Return-Path: <TurnerS@ieca.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7BA1ADFD1 for <cfrg@ietfa.amsl.com>; Sun, 12 Jan 2014 13:25:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.099
X-Spam-Level: ***
X-Spam-Status: No, score=3.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_EMAIL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8kGm2CuR9Dt for <cfrg@ietfa.amsl.com>; Sun, 12 Jan 2014 13:25:24 -0800 (PST)
Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [64.5.52.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7117F1ACC85 for <cfrg@irtf.org>; Sun, 12 Jan 2014 13:25:24 -0800 (PST)
Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 3C5A25FA3C6E6; Sun, 12 Jan 2014 15:25:13 -0600 (CST)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 0D3055FA3C69B for <cfrg@irtf.org>; Sun, 12 Jan 2014 15:25:13 -0600 (CST)
Received: from [173.73.130.192] (port=63090 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <TurnerS@ieca.com>) id 1W2SWu-0000du-0y; Sun, 12 Jan 2014 15:25:12 -0600
Content-Type: multipart/signed; boundary="Apple-Mail=_676E4B94-890C-4D8F-AF2E-17277E9B376D"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Sean Turner <TurnerS@ieca.com>
In-Reply-To: <CACsn0cm32r=92cNUOwV5Du_YC9ov8jph_wB8dHzNuqRCrvpSvw@mail.gmail.com>
Date: Sun, 12 Jan 2014 16:25:11 -0500
Message-Id: <E5019A5C-468E-4D62-86AC-D6E9D6ABFBB7@ieca.com>
References: <EFA4972A-8D88-469F-9B9C-79B36E9EE4B0@ieca.com> <CACsn0cm32r=92cNUOwV5Du_YC9ov8jph_wB8dHzNuqRCrvpSvw@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
X-Mailer: Apple Mail (2.1827)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - irtf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 173.73.130.192
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([192.168.1.4]) [173.73.130.192]:63090
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] process for cfrg blessing of [insert algorithm name here]
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jan 2014 21:25:27 -0000

On Jan 08, 2014, at 10:03, Watson Ladd <watsonbladd@gmail.com> wrote:

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

There are very few WGs that roll their own crypto mostly they just point to other work in protocols that are similar.  For example, in many of the routing protocols just do the HMAC, but what they sometimes do is re-write what’s in RFC 2104 using the terms from their protocol.  We often try to discourage them from doing this, but copying text isn’t grounds for stopping work progressing.

When a draft rolls its own crypto, we generally try to see what the cfrg things about it.

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

No I don’t think it would have been a bad thing, but I'm sure there is history about why it didn’t get changed that was before my time.

I agree that having a central resource would be a good idea I just don’t think that the central repository gets veto power.  I also want to avoid the "bring me a rock" game and get something documented that explains what’s primitives etc are good for what, which I guess is scattered around at this point but it might be good to centralize (I might even be able to do this draft :).

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

If I were kind for a day - three: one primary, one backup, and one in the wings.

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

What this highlights to me is that we need to maybe not lump every single cryptographic “thing” together.  I’m pretty sure I mixed ‘em all up in this message.

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

Streams are defined in RFC 4844 (http://tools.ietf.org/search/rfc4844).  As an author, it’s up to you to pick which stream you want your draft to go through.  The catch is the RFC 5742 review, which is the “end-run” check, so if there’s an IETF WG in that space then it’s pretty much got to go through that WG unless the WG decides to take a pass at it.

For strict crypto internet drafts (and by this I mean something like AES in some new mode and not AES in some new mode used with protocol x), there isn’t an IETF WG so really three of the streams are available: through the IETF stream as an AD sponsored internet-draft, CFRG, or Independent.  In the past, the “crypto” internet-drafts have gone through the Independent stream intended for informational status.

I’m probably okay with the Independent stream publishing informational RFCs for algorithms, the CFRG then saying yeah these algorithms would be appropriate for use here, and then the IETF WG actually standardizing it.  And, yes this seems like a horrific amount of paper work, but I think it makes the most sense given what we’ve got now.

Alternatively, I could see the CFRG publishing crypto drafts instead of the Independent stream.  Because the CFRG might work on things that aren’t ready for prime time though if this path gets taken then maybe we need some boiler plate that says “ready for prime time” and “not ready for prime time.”

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

I guess I tend to agree, and I guess it depends on the definition of compelling because we’ve definitely published multiple ways to do one thing.

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

Generally, I guess I agree with you but there’s algorithms like AES-CCM that were published stating restrictions on the amount of data to be encrypted with a single key and AES-GCM that requires counters never be reused.  

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

I’m perfectly fine with a group of different SME (subject matter experts).

spt

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