Subject: [Cfrg] CFRG Review Panel - Draft Charter

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 May 2016 13:56:04 +0100

Dear CFRG participants,
Kenny and I would like to solicit comments on the Crypto Review Panel that we announced in Buenos Aires.

We would like to solicit review of objectives and process outlined below. Please express your opinions and/or suggest your edits by the end of May 22nd. Both replies to the mailing list and directly to chairs are welcomed.

Best Regards,
Kenny and Alexey

> CFRG Review Panel
> 
> Objectives:
> CFRG is a volunteer-led activity that currently relies on the goodwill of its participants to provide review of documents. This can result in documents not receiving enough scrutiny, or examination only being forthcoming over an unacceptably long period of time. Also, there is lack of consistency between reviews of different documents.
> The CFRG Review Panel will ensure that CFRG chairs have at their disposal sufficient resources and lightweight processes to provide critical, objective, timely and consistent review of cryptographic algorithms in IRTF and IETF documents.
> The recommendations coming out of panel reviews will not be binding on CFRG, but are intended to provide high-quality input to augment the usual development process for CFRG drafts.
> Reviews will identify issues - both security issues and deployment issues - but not necessarily low-level nits and typos. Reviews will also identify relevant research, or the need for further research.
> 
> Processes:
> When CFRG chairs decide that a document would benefit from a panel review, they will select one or more reviewers and request a review within a given time period (typically 2 to 4 weeks). Reviews will be made public via the CFRG mailing list; private discussion between reviewers, authors and CFRG chairs may also take place.
> A document's authors may identify conflicts and conflicts of interest with particular panel members. Such conflicts should be notified to the CFRG chairs by the authors (or panel members) when the chairs initiate the review process.
> Not every CFRG draft needs to be reviewed by the panel; documents that are not CFRG drafts may also be reviewed by the panel.
> The CFRG chairs will make appointments to the Review Panel.  The panel will be composed of 6-8 members; it may be increased in size by the CFRG chairs should the number of documents to review necessitate the increase.
> Reviewers will be appointed to the panel for a period of 2 years, renewable. The CFRG chairs will endeavour to ensure that the Review Panel has a balanced composition covering the main technical areas of relevance to CFRG. Individuals may self-nominate or nominate others for panel membership.
> Being a panel member represents a commitment to review documents in a timely and thorough fashion; reviewers' panel membership will be rescinded at the discretion of the CFRG chairs.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 May 2016 14:12:01 +0100

As I said before I like this and think the charter text is fine.

I think it might be nice to add in that the IETF security area
directors or WG chairs are encouraged to ask for a review when
new crypto algorithm issues arise.

You might want to add something to the effect that the load (in
terms of documents to review) is not expected to be high, as a
way to encourage folks to join in. Could be useful to go back and
see if you can estimate the load based on list traffic over the
last year or two - my guess is that it'd end up with only one
document being reviewed every couple of months, which means maybe
one or two per year per panel member (but I've not checked).

S

On 10/05/16 13:56, Alexey Melnikov wrote:
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 10 May 2016 16:29:56 +0000

To repeat what I said at BA, I think this is a great idea.  I think it can also be very useful to help populate our "pipeline" of security oriented folks.  Toward that end, I would encourage getting this written up in things like ACM, and passed around the academic community.  It would probably need a couple of paragraphs (no more than that) giving brief background on IETF CFRG and how you get to do cool things like security review of the next version of TLS :)

---

From: Watson Ladd <[email-masked]>
Date: Tue, 10 May 2016 09:37:35 -0700

> To repeat what I said at BA, I think this is a great idea.  I think it can also be very useful to help populate our "pipeline" of security oriented folks.  Toward that end, I would encourage gettin…

So we are changing the IETF process to enable this panel to review all
drafts that might benefit, not just ones submitted to CFRG? (CC'ng
SAAG because I feel people would be interested and they already have a
similar process, but more extensive)

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 10 May 2016 16:39:06 +0000

> So we are changing the IETF process to enable this panel to review all drafts
> that might benefit, not just ones submitted to CFRG?

There is no IETF/IRTF process that says CFRG can only review things given to them. :)

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 May 2016 17:46:01 +0100

> similar process, but more extensive)

No there is no formal change to IETF process here.

If the cfrg review panel idea works well, that's something that
the IETF could consider later.

In the meantime, if cfrg have some more qualified folks with
cycles to do reviews, then those reviews are very welcome and
can be fed into the current IETF process, in the same way as
comments from any qualified person.

Cheers,
S.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 May 2016 23:14:33 +0300

Hi.

> Reviews will identify issues - both security issues and deployment issues - but not necessarily low-level nits and typos. Reviews will also identify relevant research, or the need for further resea…

Some things I think the output from such a review should contain:
Differentiation - how is this crypto different from common crypto. If there is a proposal for using some new (national or not) block cipher, the review should say in what ways this is better than AES. I mean, nobody’s going to propose in 2016 something that isn’t better than AES at least in some respects. If it’s a signature algorithm, I’d like to know what useful property it has that RSA, ECDSA, or EdDSA don’t. Speed is a differentiator; block size is another; some elegant security proof that cannot be done to other algorithms is yet another. Or maybe some new and useful property.
Use cases - not every algorithm is better for every use case. The group is considering AES-GCM-SIV. If that was under review, the review would note the differentiator - that nonce reuse leads to far milder consequences than in current algorithms. But nonce reuse doesn’t happen in many of our favorite protocols: SSH, TLS, IPsec, S/Mime, so AES-GCM-SIV is not a good algorithm for any of those, or at least no better than regular AES-GCM. I’d like a review to tell what kind of protocols or use cases might benefit from an algorithm with this property, such as multicast IPsec with multiple senders or group unicast IPsec such as Cisco’s GET-VPN.  
Some conclusion from reviewing the research. I’m looking for a subjective assessment of how confident we are that this algorithm is good; Whether it is safe to begin using it in protocols that protect high-value data.

Yoav

> On 10 May 2016, at 3:56 PM, Alexey Melnikov <[email-masked]> wrote:
> 
> Dear CFRG participants,

---

From: [email-masked]
Date: Wed, 11 May 2016 08:29:34 +0300

Hi Yoav,
I generally agree with what you have outlined. The problem is that how these issues could be addressed within proposed 2-4 weeks period. As for me CFRG should be focused on crypto: implementation issues or suitability for a specific protocol  should be left for other working groups. As for crypto it is obvious that 2-4 weeks period is not enogh for profound cryptoanalysis. I think that the best reviewers could do - is to present a state-of-the-art in cryptoanalysis of the proposed mechanism, and possibly show what issues are missed. So, to my mind, such a review should contain a list of publicly availiable results of cryptanalysis, or results which could have a relation to the cryptanalysis of the proposed mechanism.
Grigory
--
Отправлено из Mail.Ru для Android вторник, 10 мая 2016г., 23:14 +03:00 от Yoav Nir < [email-masked]> :

>*  Differentiation - how is this crypto different from common crypto. If there is a proposal for using some new (national or not) block cipher, the review should say in what ways this is better than AES. I mean, nobody’s going to propose in 2016 something that isn’t better than AES at least in some respects. If it’s a signature algorithm, I’d like to know what useful property it has that RSA, ECDSA, or EdDSA don’t. Speed is a differentiator; block size is another; some elegant security proof that cannot be done to other algorithms is yet another. Or maybe some new and useful property.
>*  Use cases - not every algorithm is better for every use case. The group is considering AES-GCM-SIV. If that was under review, the review would note the differentiator - that nonce reuse leads to far milder consequences than in current algorithms. But nonce reuse doesn’t happen in many of our favorite protocols: SSH, TLS, IPsec, S/Mime, so AES-GCM-SIV is not a good algorithm for any of those, or at least no better than regular AES-GCM. I’d like a review to tell what kind of protocols or use cases might benefit from an algorithm with this property, such as multicast IPsec with multiple senders or group unicast IPsec such as Cisco’s GET-VPN.  
>*  Some conclusion from reviewing the research. I’m looking for a subjective assessment of how confident we are that this algorithm is good; Whether it is safe to begin using it in protocols that protect high-value data.
>
>Yoav
>>On 10 May 2016, at 3:56 PM, Alexey Melnikov < [email-masked] > wrote:
>>Dear CFRG participants,
>>>Objectives: CFRG is a volunteer-led activity that currently relies on the goodwill  of its participants to provide review of documents. This can result in  documents not receiving enough scrutiny, or examination only being  forthcoming over an unacceptably long period of time. Also, there is lack of consistency between reviews of different documents. The CFRG Review Panel will ensure that CFRG chairs have at their  disposal sufficient resources and lightweight processes to provide  critical, objective, timely and consistent review of   cryptographic  algorithms in IRTF and IETF  documents. The recommendations coming out of panel reviews will not be binding on  CFRG, but are intended to provide high-quality input to augment the  usual development process for CFRG drafts. Reviews will identify issues - both security issues and deployment  issues - but not necessarily low-level nits and typos. Reviews will also  identify relevant research, or the need for further research.
>>>Processes: When CFRG chairs decide that a document would benefit from a panel review,  they will select one or more reviewers and request a review within a  given time period (typically 2 to 4 weeks). Reviews will be made public  via the CFRG mailing list; private discussion between reviewers, authors  and CFRG chairs may also take place. A document's authors may identify conflicts and conflicts of interest  with particular panel members. Such conflicts should be notified to the  CFRG chairs by the authors (or panel members) when the chairs initiate  the review process. Not every CFRG draft needs to be reviewed by the panel; documents that  are not CFRG drafts may also be reviewed by the panel. The CFRG chairs will make appointments to the Review Panel.  The panel  will be composed of 6-8 members; it may be increased in size by the CFRG  chairs should the number of documents to review necessitate the increase. Reviewers will be appointed to the panel for a period of 2 years,  renewable. The CFRG chairs will endeavour to ensure that the Review  Panel has a balanced composition covering the main technical areas of  relevance to CFRG. Individuals may self-nominate or nominate others for  panel membership. Being a panel member represents a commitment to review documents in a  timely and thorough fashion; reviewers' panel membership will be  rescinded at the discretion of the CFRG chairs.
>>
>>

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 11 May 2016 12:58:46 +0700

> On 11 May 2016, at 03:14, Yoav Nir <[email-masked]> wrote:
> But nonce reuse doesn’t happen in many of our favorite protocols: SSH, TLS, IPsec, S/Mime, so AES-GCM-SIV is not a good algorithm for any of those, or at least no better than regular AES-GCM. I’d like a review to tell what kind of protocols or use cases might benefit from an algorithm with this property, such as multicast IPsec with multiple senders or group unicast IPsec such as Cisco’s GET-VPN.

Full disclosure, since this is somewhat public by now anyways: It does happen in TLS. The chairs received an abstract on a soon-to-be published paper in the matter late yesterday as did Stephen Farrell (as you're aware you're not affected :)). One of the chairs has a full working copy/author version including PoC code for our attack.

To that extent may I ask the following question: with proposals like AES-GCM-SIV, should I press cryptographers that initially submitted to CAESAR to submit drafts to CFRG, fill up everyones pipeline and get CFRG into dead-lock? How do we deal with that problem? How's CFRG better/different for IETF than a proper crypto competition (even if some take ages, or seem to be a never ending story).

Aaron

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 11 May 2016 11:39:50 +0000

Hi Yoav,

Thanks for these suggestions. We're most definitely open to clarifying the
scope of reviews and the expectations placed on reviewers.

Best

Kenny 

On 10/05/2016 21:14, "Cfrg on behalf of Yoav Nir" <[email-masked]
on behalf of [email-masked]> wrote:

>
>
>
>Hi.
>
>
>I like the idea, but I would like to have more clarity on what we expect
>such a review to contain.  We currently have this:
>
>
>
>Reviews will identify issues - both security issues and deployment issues
>- but not necessarily
> low-level nits and typos. Reviews will also identify relevant research,
>or the need for further research.
>
>
>
>* Differentiation - how is this crypto different from common crypto. If
>there is a proposal for using some new (national or not) block cipher,
>the review should say in what ways this is better than AES. I mean,
>nobody’s going to propose in 2016 something
> that isn’t better than AES at least in some respects. If it’s a
>signature algorithm, I’d like to know what useful property it has that
>RSA, ECDSA, or EdDSA don’t. Speed is a differentiator; block size is
>another; some elegant security proof that cannot be
> done to other algorithms is yet another. Or maybe some new and useful
>property.
>* Use cases - not every algorithm is better for every use case. The group
>is considering AES-GCM-SIV. If that was under review, the review would
>note the differentiator - that nonce reuse leads to far milder
>consequences than in current algorithms.
> But nonce reuse doesn’t happen in many of our favorite protocols: SSH,
>TLS, IPsec, S/Mime, so AES-GCM-SIV is not a good algorithm for any of
>those, or at least no better than regular AES-GCM. I’d like a review to
>tell what kind of protocols or use cases might
> benefit from an algorithm with this property, such as multicast IPsec
>with multiple senders or group unicast IPsec such as Cisco’s GET-VPN.
>* Some conclusion from reviewing the research. I’m looking for a
>subjective assessment of how confident we are that this algorithm is
>good; Whether it is safe to begin using it in protocols that protect
>high-value data.
>
>
>
>
>Yoav
>
>
>We would like to solicit review of objectives and process outlined below.
>Please express your opinions and/or suggest your edits by the end of May
>22nd. Both replies to the mailing list and directly to chairs are
>welcomed.
>
>
>Best Regards,
>Kenny and Alexey
>
>
>CFRG Review Panel
>
>
>
>
>
>
>Objectives:
>
>
>CFRG is a volunteer-led activity that currently relies on the goodwill of
>its participants
> to provide review of documents. This can result in documents not
>receiving enough scrutiny, or examination only being forthcoming
> over an unacceptably long period of time. Also, there is lack of
>consistency between reviews of different documents.
>
>
>The CFRG Review Panel will ensure that CFRG chairs have at their disposal
>sufficient resources
> and lightweight processes to provide critical, objective, timely and
>consistent review of cryptographic algorithms
> in IRTF and IETF documents.
>
>
>The recommendations coming out of panel reviews will not be binding on
>CFRG, but are intended
> to provide high-quality input to augment the usual development process
>for CFRG drafts.
>
>
>Reviews will identify issues - both security issues and deployment issues
>- but not necessarily
> low-level nits and typos. Reviews will also identify relevant research,
>or the need for further research.
>
>
>
>
>
>
>Processes:
>
>
>When CFRG chairs decide that a document would benefit from a panel
>review, they will select
> one or more reviewers and request a review within a given time period
>(typically 2 to 4 weeks). Reviews will be made public via
> the CFRG mailing list; private discussion between reviewers, authors and
>CFRG chairs may also take place.
>
>
>A document's authors may identify conflicts and conflicts of interest
>with particular panel
> members. Such conflicts should be notified to the CFRG chairs by the
>authors (or panel members) when the chairs initiate the
> review process.
>
>
>Not every CFRG draft needs to be reviewed by the panel; documents that
>are not CFRG drafts
> may also be reviewed by the panel.
>
>
>The CFRG chairs will make appointments to the Review Panel.  The panel
>will be composed
> of 6-8 members; it may be increased in size by the CFRG chairs should
>the number of documents to review necessitate the increase.
>
>
>Reviewers will be appointed to the panel for a period of 2 years,
>renewable. The CFRG chairs
> will endeavour to ensure that the Review Panel has a balanced
>composition covering the main technical areas of relevance
> to CFRG. Individuals may self-nominate or nominate others for panel
>membership.
>
>
>Being a panel member represents a commitment to review documents in a
>timely and thorough
> fashion; reviewers' panel membership will be rescinded at the discretion
>of the CFRG chairs.
>
>
>
>
>
>

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 11 May 2016 14:10:54 +0000

Hi,

On 11/05/2016 06:58, "Cfrg on behalf of Aaron Zauner"
<[email-masked] on behalf of [email-masked]> wrote:

>>tell what kind of protocols or use cases might benefit from an algorithm
>>with this property, such as multicast IPsec with multiple senders or
>>group unicast IPsec such as Cisco’s GET-VPN.
>
>Full disclosure, since this is somewhat public by now anyways: It does
>happen in TLS. The chairs received an abstract on a soon-to-be published
>paper in the matter late yesterday as did Stephen Farrell (as you're
>aware you're not affected :)). One of the chairs has a full working
>copy/author version including PoC code for our attack.
>
>To that extent may I ask the following question: with proposals like
>AES-GCM-SIV, should I press cryptographers that initially submitted to
>CAESAR to submit drafts to CFRG, fill up everyones pipeline and get CFRG
>into dead-lock?
>How do we deal with that problem? How's CFRG better/different for IETF
>than a proper crypto competition (even if some take ages, or seem to be a
>never ending story).

Chairs' general preference is to wait for the outcomes of crypto
competitions and then adopt (and possibly adapt) winners or selected
finalists. We will do that with CASEAR once it eventually reaches its
conclusion. 

However, in this instance, a group of authors came to CFRG with a specific
proposal. We polled for feedback on the wisdom of accepting the proposal.
There was not a strong consensus for doing so, with some people being
strongly opposed, and other people being in favour. Chairs were then
required to make a decision on what to do. We decided to adopt the draft.
Some people continue to disagree with our decision. That's understandable,
but it's not going to change the decision that we made.

People are perfectly at liberty to continue to complain, but we would very
much prefer if their energy was instead directed towards analysing the
draft and providing useful feedback to the authors.

Regards,

Kenny