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

[David McGrew <[e-mail]>]

Hi Sean,

thanks for sharing your thoughts; you raise a lot of good points.   More 
inline:

On 01/12/2014 04:25 PM, Sean Turner wrote:
> On Jan 08, 2014, at 10:03, Watson Ladd <[e-mail]> wrote:
>
>> On Wed, Jan 8, 2014 at 12:16 AM, Sean Turner <[e-mail]> 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.

Agreed.   Historically, CFRG has focused on algorithms and not 
protocols, and the IETF security area groups have done crypto protocols, 
and not algorithms; that is, IETF WGs have felt confident to design 
protocols that use cryptographic primitives.   Now, the CFRG charter 
does not limit itself to algorithms, it refers to "techniques" and 
"mechanisms", so its past focus has not been limited by its charter.   
Going forward, it could do more protocol oriented work, if that would be 
fruitful.

Our aim should be to (better) isolate the security-relevant aspects of a 
crypto mechanism.  For instance, AEAD provided better isolation than 
earlier DIY methods.  It is also possible to specify a crypto protocol 
in a way that is transport-independent, which could be an avenue for 
us.   I think you hit on a key point below: the more proactive we are, 
the more successful we will be.

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

I agree with you here, but let me add that I think we could improve 
things by structuring/defining the relationship between IETF and CFRG in 
a way that brings CFRG more into the IETF process.   CFRG should not 
have veto power, but documenting the response of the RG could become 
part of the vetting process for new uses of crypto, for instance.    On 
the CFRG side, we would need to make sure that we have enough people 
with the skills and time to do such vetting.

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

When someone has a crypto technique or a requirements or security 
analysis that they think should be picked up by the Research Group, I 
ask that they write up an email formally suggesting that adoption, and 
send it to the list.   Ideally, the subject line should contain 
something like "proposal for RG adoption" or some similar text.   I 
think this way of doing things will provide as much transparency as 
possible, which is good.

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

This is a good suggestion.  It seems that some coordination would be 
good here.   Perhaps we could get someone in CFRG to take on the 
responsibility of handling coordination with the ISE, and triage the 
drafts to find the ones that need the most attention, and match 
volunteer reviewers from CFRG to drafts as needed.

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

Agreed, it would be useful to come up with some boilerplate that could 
be added to RFCs, which captures the CFRG opinion.  This sort of text 
could also be useful for endorsing work that we feel is ready for 
adoption.   I need to think more about what sort of categories we would 
want to define, but I like this idea.


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

The IETF ISE should be willing to publish informational RFCs that 
describe existing work, such as a national cipher, in order to introduce 
that work to the Internet community and to provide an accessible 
specification.   I don't think CFRG can or should be able to prevent any 
such publication.   But what would be good is to record the CFRG opinion 
on the algorithm.   This could be done in a subsection of the RFC, for 
instance, or it could be written up in a separate RFC (along the lines 
of cipher-catalog).

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

My opinion on the lack of security proof: no, we should not prevent 
publication because of a lack of a security proof.   A proof is highly 
desirable when dealing with a complex protocol or algorithm because it 
shows that security is equivalent to some easier-to-understand crypto 
challenge that has not yet been broken.   But new ciphers, for instance, 
do not have such reductions; we can't reasonably expect a proof of 
security for CLEFIA, say.   So while we might prefer proofs, we should 
not require them.

Watson had suggested, a couple of weeks back, that CFRG consider writing 
up a statement of what sort of proofs and models were best, and I liked 
that idea.   A document like that could also make the job of explaining 
security to IETF WGs easier.

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

This is a really valid question.   I'll add that the people who are 
designing systems to solve real-world problems are the people that we 
want to use well-reviewed, proven secure algorithms, and they are the 
ones who will be asking the question that you pose above.

It would be valuable if there were a body of literature describing best 
practices for crypto implementations, which was easily accessible to 
crypto practitioners.   Here I mean accessible in the sense of "I can 
understand the security properties and how to implement it" as well as 
"I can find and download the document easily".    This goal gets beyond 
the current CFRG charter, I think.   To give academic cryptographers 
"full credit" for participating, it would be useful to establish a 
peer-reviewed journal for the publication of these documents.

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

The IRTF approach to a situation in which there is a diversity of 
opinion on a draft is to document the different opinions.   I think that 
is a good approach to take when there is not a consensus, and I think it 
could be useful in a situation like you describe.

David

>
>
>>> 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
>>> [e-mail]
>>> 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
>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg