Subject: [Cfrg] would it be a good idea for CFRG to try review algorithm documents?

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Dec 2015 01:38:43 +0000

Hiya,

The IESG has another of those conflict reviews on Dec 17. In this
case I doubt there's a process conflict (see below for details)
as this is documenting some more details of the GOST suite which,
as a national algorithm suite, kind of just is what it is.

But as a non-cryptographer, I'd be happier if in future things
like this (or non-national "vanity" algorithm descriptions) had
gotten some review from CFRG, however I'm not sure if folks here
would be generally willing to do that kind of review.

The reason I'd like review is so that we have a better idea of any
issues or caveats or cautions when/if the proponents of such
algorithms come calling at the IETF's door for code points to
use their algorithm in TLS/IPsec or whatever. (Which they usually
do do.)

If this was done informally and we got prompt and good reviews I
think that'd be a fine thing, but if we try formalise it, then we
might end up with some tricky process issues. And I'm not sure if
folks here would be willing to do such reviews or able to get them
done when needed (there aren't too many drafts like this but they
do come along now and then in a reasonably constant dribble).

Thoughts welcome,
Cheers,
S.

PS: I've cc'd Nevil who is the independent submissions editor. I
do know there's some review done by folks before he sends such
documents to the IESG for 5742 review, but I'm not sure if the
kind of thing I'm asking about here is part of that. I do know
there are more people on this list than on Nevil's review team
though:-)

-------- Forwarded Message --------
Subject: [saag] another conflict review of some GOST stuff
Date: Thu, 10 Dec 2015 01:16:31 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked] <[email-masked]>

Hiya,

On Dec17, the IESG will also be doing the conflict review for a
draft [1] that documents some more about using GOST algorithms.

Since we've typically handled national algorithms in this manner
(basic alg details are documented as independent submission
stream RFCs) I think this one does not represent a conflict with
ongoing IETF work or process. But if I'm wrong, please do let me
know.

Should someone want code points for using these algorithms in IETF
protocols, that'd of course go through the normal consensus process.
See RFC 5742 [2] for details of what this bit of process is about.

If you have comments on the draft content then please send those
to the authors and cc the independent submissions editor, Nevil
Brownlee ([email-masked]).

Cheers,
S.

[1] https://datatracker.ietf.org/doc/draft-smyshlyaev-gost-usage/
[2] https://tools.ietf.org/html/rfc5742

_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: Yoav Nir <[email-masked]>
Date: Thu, 10 Dec 2015 11:25:42 +0200

Hi, Stephen.

> On 10 Dec 2015, at 3:38 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 

The kind of review you might get in an IETF WG or in a IRTF RG is somewhere between a few hours to a few days of work from several people. 

That is likely enough to review some vanity crypto that someone thought up all by himself (example: [1]). It is not enough for a full analysis of cryptography that actually works. The draft you are talking about is GOST crypto. GOST has a team of good cryptographers working full-time on these algorithms. I doubt a cursory review by this list could find any new weaknesses. We might be able to point at previous work published about such an algorithm, or point out that the block cipher uses a 64-bit block. But I don’t think it’s likely to find new stuff.

Yoav

[1] http://www.ietf.org/mail-archive/web/cfrg/current/msg06805.html

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Dec 2015 09:58:08 +0000

Hiya,

On 10/12/15 09:25, Yoav Nir wrote:
>> But as a non-cryptographer, I'd be happier if in future things like
>> this (or non-national "vanity" algorithm descriptions) had gotten
>> some review from CFRG, however I'm not sure if folks here would be
>> generally willing to do that kind of review.
> 
> The kind of review you might get in an IETF WG or in a IRTF RG is
> somewhere between a few hours to a few days of work from several
> people.
> 
> That is likely enough to review some vanity crypto that someone
> thought up all by himself (example: [1]). It is not enough for a full
> analysis of cryptography that actually works. The draft you are
> talking about is GOST crypto. GOST has a team of good cryptographers
> working full-time on these algorithms. I doubt a cursory review by
> this list could find any new weaknesses. We might be able to point at
> previous work published about such an algorithm, or point out that
> the block cipher uses a 64-bit block. But I don’t think it’s likely
> to find new stuff.

Agreed.

Pointing at previous work that affects how to sensibly use an
algorithm in IETF protocols, or spotting details that are badly
documented, would be what we're after here, not new cryptanalytic
results. (If someone had those, and was gonna publish, they'd
publish elsewhere for sure.)

The reason I think that could be valuable though is that I do
think there's expertise on this list that's not available in
the IETF and I'd like to avoid a situation where cryptographers
come back to us some years later saying "WTF!!? the IETF has said
how to use <foo> for <bar>, but <biffle et al> showed years ago
that that's only safe for 2^N packets and the <blah> setting
has to be <fuffle>."

I figure it's reasonably likely that the proponents of the
<foo> algorithm might omit such details, not out of
crypto-badness but just for normal human-nature reasons or
because they assume that everyone using <foo> should know
that already.

Cheers,
S.

---

From: Björn Edström <[email-masked]>
Date: Thu, 10 Dec 2015 13:18:19 +0100

I 100% support the view that cryptographic proposals should be sanity
checked by CFRG or another appropriate WG/RG. Specifically for the
reason you mention Stephen: There may have been recent research that
invalidates some security assumptions that were previously held.

Cheers
Björn

On Thu, Dec 10, 2015 at 10:58 AM, Stephen Farrell
<[email-masked]> wrote:
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 10 Dec 2015 15:00:53 +0000

GOST has been reviewed and analyzed by the cryptographic community
(academia included) for ages (well, decades, really). I’ve seen several
publications. As I recall, the only significant weakness found was related
to related-keys <pun intended :>. Of course it uses 64-bit blocks in the
world where (most) everybody embraced 128-bit, and some toy with 256-bit
block ciphers. 

However distinguished this body of cryptographers is, I doubt anything new
would pop up.

But by all means, review away! :-)

P.S. Isn’t Russia moving to Grasshopper (128-bit block cipher), making it
their new standard (“GOST” is an abbreviation for “State Standard”, in
case anybody cares to know :)? I.e., isn’t the “old” GOST becoming
irrelevant?
-- 
Regards,
Uri Blumenthal

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 10 Dec 2015 18:57:44 +0300

Hi Uri,

"Grasshopper" ("Kuznechik in Russian") is an official standard in Russia since June 2015.
However, the "old" GOST cipher is continued to be used, now it is nicknamed "Magma".

What about the draft in question - it is more about using hash function for the purposes
of key derivation and about public key cryptography, much less about using ciphers
(only key wrapping is discussed). It also includes definitions of Elliptic curves
(including twisted Edwards curves) that are to be used in GOST (256 bit and 512 bits).

Regards,
Valery Smyslov.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 10 Dec 2015 11:33:57 -0800

This document is not the old GOST algorithm - that was published long ago.  This is a 128-bit block algorithm.

Jim

> -----Original Message-----
> From: Cfrg [mailto:[email-masked]] On Behalf Of Blumenthal, Uri - 0553 -
> MITLL
> Sent: Thursday, December 10, 2015 7:01 AM
> To: Björn Edström <[email-masked]>; Stephen Farrell <[email-masked]>
> Cc: [email-masked]; Nevil Brownlee <[email-masked]>
> publications. As I recall, the only significant weakness found was related to
> related-keys <pun intended :>. Of course it uses 64-bit blocks in the world where
> (most) everybody embraced 128-bit, and some toy with 256-bit block ciphers.
> 
> P.S. Isn’t Russia moving to Grasshopper (128-bit block cipher), making it their
> new standard (“GOST” is an abbreviation for “State Standard”, in case anybody
> cares to know :)? I.e., isn’t the “old” GOST becoming irrelevant?
> --
> Regards,
> Uri Blumenthal
> 
> 
> 
> 
>

---

From: "Григорий Маршалко" <[email-masked]>
Date: Thu, 10 Dec 2015 21:45:26 +0000

Hi, 

I think, some clarification for GOST algorithms is needed, because sometimes it is not clear what
GOST algo is being discussed.
Now we have the following cryptostandards in Russia:

GOST R 34.10-2012 Signature and verification processes of [electronic] digital signature -- it is a
part of ISO/IEC 14888-3 standard, where it is referred as EC-RDSA;
GOST R 34.11-2012 Hash function -- which specifies 2 hash functions from Streebog family, sometimes
referred as Streebog-512 and Streebog-256;
GOST R 34.12-2015 Block ciphers -- which specifies 2 algorithms: Magma (old GOST 28147-89 with
64-bit block and 256-bit key with specified s-boxes) and new Kuznyechik (Grasshopper) with 128-bit block
and 256-bit key;
GOST R 34.13-2015 Block cipher modes - MAC and other cipher modes.

As for the main topic, the more independent review is performed -- the better. I'd like to mention ISO
practice, where we have some selection criteria for cryptoalgorithms and protocols. These criteria
are rather general, but for new proposals they usually result in a list arguments supporting
submission. 
So, together with the description of mechanisms an expert provides design rationale, implementation
results and results of third party cryptanalysis. Combined together in memo/slides they
significantly speed up expertise, since you can see the whole picture at the beginning.

As for GOST algorithms, they all have received a very intensive independent cryptanalysis (even a newely born
Kuznyechik), some of them (EC-RDSA and Streebog has also security proofs in some models), and I
personally do not know any cryptanalytic results in reasonable settings (as it was also mentioned early in mailing for GOST 28147-89) which can affect the
security of a real cryptograhic system. So, since the mentioned draft adresses the use of well-known
and widely-studied algorithms (like HMAC and DIffie-Hellman) with GOST algorithms, I see no problems with the
security.

Regards,
Grigory Marshalko,
expert,
Technical committee for standardisation "Cryptography and security mechanisms" (ТC 26)
www.tc26.ru

---

From: Nevil Brownlee <[email-masked]>
Date: Fri, 11 Dec 2015 11:23:15 +1300

Hi Björn et al:

Hmm.  I try to find several crypto experts to review 'security' drafts
in detail as part of the Independent Stream review process.
However, asking CFRG to take a look too could be a good idea - as
long as the CFRG members wouldn't regard such requests as spam?

Cheers, Nevil (Independent Submissions Editor)

-- 
Nevil Brownlee (ISE), [email-masked]

-- 
---------------------------------------------------------------------
  Nevil Brownlee                          Computer Science Department
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

---

From: Björn Edström <[email-masked]>
Date: Thu, 10 Dec 2015 23:55:12 +0100

With the proper expectations from all parties involved I personally
see no issues with this. Then again, I'm not really a strong voice in
this community so better listen to more people. :-)

I would not expect the CFRG participants to put in hours or days of
novel research into submissions. I would expect CFRG participants to
be reasonably up to speed with their line of research, and would be
able to point to research that supports or cast doubt on the viability
of a proposal. (Basically Stephens example in his response to Yoav).

The situation I'd like to avoid happening to the Internet is basically this:

1) A strong security construct is standardized as RFC NNNN that has
years and years of research behind it. The security is deemed viable.
There is much to rejoice.
2) A couple of years go by.
3) A draft is written that points to the security of RFC NNNN (e.g.
some integration to some other technology).
4) Approximately at the same time some new research is published that
breaks RFC NNNN in a non-negligible way.
5) The problem in 4 is not caught.

I expect that CFRG would catch 4 so precautionary measures can be
taken w.r.t. to the draft.

So my 2 cents here would be that I can live with more emails if the
end result is better quality output.

Best
Björn

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Dec 2015 23:29:12 -0500

> do come along now and then in a reasonably constant dribble).

I would prefer that neither the IETF nor the IRTF did any crypto reviews
and no RFCs were issued or needed unless it was for an algorithm to be used
as RECOMMENDED or REQUIRED.

The rationale for this is that regardless of what status IETF considers a
document to have, outsiders naturally assume that every RFC is an IETF
recommendation. Trying to teach the world otherwise is futile.

While some protocols do have limited code points available, it is almost
certainly possible to extend these by allocating a code point for and
extension scheme. And I would use OIDs for the extension scheme rather than
IANA issued identifiers to further distance IETF.

Either review thoroughly or not at all. Leading people to think the
algorithm has been reviewed when it has not is only going to lead to tears.

---

From: Björn Edström <[email-masked]>
Date: Fri, 11 Dec 2015 12:41:12 +0100

Hi Phillip.

I share your worry and I agree. Avoid crypto reviews, and try to avoid
issuing RFC:s for constructs that do not have thorough academic
review.

However, I don't see drafts using constructs being sanity checked by
CFRG as giving them a "seal of approval". I see it as a filter to
prevent accidents (as in the scenario I wrote in my email).

So to clarify, both of these would be bad:

*) An RFC is issued for a construct that is obviously broken to CFRG.
It was not run by CFRG.
*) An RFC is issued for a construct that has not been thoroughly
researched. It's run by CFRG and that is seen as the RG giving a "seal
of approval" (which is not the case).

Both of those would hurt trust in the process, so it has to be handled
delicately.

Thoughts?

Best
Björn

On Fri, Dec 11, 2015 at 5:29 AM, Phillip Hallam-Baker
<[email-masked]> wrote:
> I would prefer that neither the IETF nor the IRTF did any crypto reviews and
> no RFCs were issued or needed unless it was for an algorithm to be used as
> RECOMMENDED or REQUIRED.
>

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 Dec 2015 16:12:18 +0100

> would be generally willing to do that kind of review.

Wouldn't it make more sense for the CFRG to work on a document that said
that vanity algorithms (state-sponsored or not) are harmful to Internet
security, and should not be published as RFCs at all?

In my opinion, the CFRG should recommend the best algorithms and
approaches for network security uses (which may include state-sponsored
crypto).  In my mind, that includes recommending a small set of
state-of-the-art algorithms in each category of cryptographic primitive,
and actively discourage proliferation of algorithms as we've seen that
this reduce overall Internet security.  As a side-note, it is important
that this doesn't come in conflict with the ability of deploying
experiments -- so the CFRG could recommend that protocols include
flexible negotiation approaches (the SSH model with text string
algorithm names has been successful here -- the binary and regulated TLS
model has not been as good).

Otherwise I fell that the CFRG becomes a political rubber-stamp
organization.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 Dec 2015 16:12:43 +0100

> issuing RFC:s for constructs that do not have thorough academic

...and has support among network security implementers in the global
Internet community.  The CFRG does not live in a vacuum, there should be
demand for what it publishes.  There are constructs with plenty of
academic reviews that are completely pointless to publish through the
CFRG.

/Simon

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 11 Dec 2015 16:16:49 +0000

> security, and should not be published as RFCs at all?

Isn't AES arguably a vanity algorithm?  What's the criteria?

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 11 Dec 2015 16:25:35 +0000

Hi Simon, Rich,

> Isn't AES arguably a vanity algorithm?  What's the criteria?

Well, before you go there, I think we can agree that folks
do come along to the IETF all the time wanting their fav
algorithms usable on the Internet. And sometimes those folks
can write a law saying "you must be able to use <this>."
And that won't stop. We know already that there are some
more on the way in the not too distant future.

Now, even if we don't like that or consider it a good idea,
I don't think we can fully ignore it (much as I'd like it
if we could).

So the suggestion here is to try ensure that we're not as
open to doing the wrong thing as we might otherwise be nor
as perhaps some other venues still are.

Of course, none of this means that we would ever want any such
algorithm as MTI for one of our standards, and indeed Rich has
promised us a draft along those lines (which I'm sure we'll
see popping out soon:-). That draft though is better off
being an IETF BCP and not a CFRG product. (I'll be sure to
get feedback here though.)

S.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 11 Dec 2015 16:29:01 +0000

> So the suggestion here is to try ensure that we're not as open to doing the
> wrong thing as we might otherwise be nor as perhaps some other venues
> still are.

Totally agree.  I was just trying to point out how hard the problem is. :)  or maybe :(

---

From: Tom Ritter <[email-masked]>
Date: Fri, 11 Dec 2015 10:57:46 -0600

> world where (most) everybody embraced 128-bit, and some toy with 256-bit

I thought there were several slide attacks on GOST (I assume the old
'Magma' version, but I am unsure) that significantly weaken it from
it's purported keylength (but are still not computable breaks.)  I
believe they kicked off with Isobe's paper in 2011[0] and then were
improved by a number of people e.g. [1].

-tom

[0] https://www.iacr.org/archive/fse2011/67330297/67330297.pdf
[1] https://eprint.iacr.org/2011/558.pdf

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Dec 2015 12:38:25 -0500

> Otherwise I fell that the CFRG becomes a political rubber-stamp

+1

I will just add that if the IETF wants to do text strings, I would prefer
they be URNs rather than in an IANA registry. The best way to avoid capture
of a control point is to eliminate it.

Back in the days before the cryptowars were the big issue, there was the
'cyberporn' circus when the establishment attempted to gain control over
the Web by scaremongering about pornography based on a ridiculous survey
that had found 80% of the material in the USENET porn newsgroups were
pornographic (I'm shocked).

As part of the legal strategy against COPA, the W3C got involved in an
effort to developing a labelling system for Web sites. Which of course the
would-be censors loved because after getting the bill through, the
Christian Right and Marxist Feminists could fight over control of the
regulation boards. Unfortunately the idiot in charge of the project tried
to build something that was meant work. So I proposed they use URIs as
identifiers for the labelling schemes. Once it was clear that there would
be no single nexus of control, the tactical alliance between the two groups
collapsed.

I see the situation with GOST as being very similar. The requirement to use
a state sponsored crypto will be used as a justification for stripping out
DNSSEC records that don't meet the state crypto requirements. Or at least
that would happen as soon as people started using DANE to secure
certificates.

Back in 1995 we could have easily used DNSSEC instead of X.509 as the basis
for distributing the WebPKI. The reason we didn't was precisely the fact
that it would concentrate control in one place and make that too much of a
target.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 11 Dec 2015 21:27:24 +0000

>[1] https://eprint.iacr.org/2011/558.pdf

Funny, I missed the Dinur--Shamir’s paper! Oh well. Yes, it’s against the
old GOST, now named “Magma” (as opposed to the new one named “Grasshopper”
or “Kuznechik").

The summary is: Isobe’s attack is 2^224 time complexity, 2^32 known
plaintext pairs (half the dictionary), 2^64 memory.
Shamir’s attack: either 2^192 time complexity, 2^64 data (full
dictionary), and 2^36 memory - or 2^236 time complexity, 2^32 data, and
2^19 memory.

The best attack shaves 64 bits (a lot!) off the 256-bit key, at the cost
of pretty much having the complete dictionary, and still impractical
computations. The authors pointed out that GOST’s simplistic key schedule
contributes to the effectiveness of these attacks.

Very neat result. Of course those, whose data is protected by “Magma”
don’t need to lose sleep just yet, as the authors stated. :-)

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 13 Dec 2015 23:00:53 +0100

> Isn't AES arguably a vanity algorithm?  What's the criteria?

I suppose my definition of vanity algorithm is something along the lines
of: one for which there aren't overall sufficient _technical_ arguments
to prefer it to other algorithms for Internet-wide usage.  I believe AES
was significantly (technically) better than what we had (RC4, (3)DES,
Blowfish) before AES was announced, so therefor I wouldn't consider AES
a vanity algorithm.  Today there are alternatives with better properties
(speed, side-channel resistance) but those are fairly soft arguments so
migration happens slowly.  I believe the biggest problem with AES is
that it is used way too often in non-AEAD modes though.

/Simon