Re: [Cfrg] RFC 5742 conflict review for draft-dolmatov-kuznyechik

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Mon, 01 February 2016 14:26 UTC

Return-Path: <prvs=18391cd231=uri@ll.mit.edu>
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 956CD1A9145 for <cfrg@ietfa.amsl.com>; Mon, 1 Feb 2016 06:26:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 cDG_FsfEDzT9 for <cfrg@ietfa.amsl.com>; Mon, 1 Feb 2016 06:26:33 -0800 (PST)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 03F491A1A9A for <cfrg@irtf.org>; Mon, 1 Feb 2016 06:26:32 -0800 (PST)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u11EQJov011308; Mon, 1 Feb 2016 09:26:19 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Yoav Nir <ynir.ietf@gmail.com>, Simon Josefsson <simon@josefsson.org>
Thread-Topic: [Cfrg] RFC 5742 conflict review for draft-dolmatov-kuznyechik
Thread-Index: AdFc/IqEbsNeEPsm8UW9VpkHszoW7Q==
Date: Mon, 01 Feb 2016 14:26:29 +0000
Message-ID: <20160201142637.17788998.41654.48478@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="===============0504601093=="
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-01_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602010246
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/NvuM4a_c02chZROq-0wKJ5RhXBw>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, Nevil Brownlee <rfc-ise@rfc-editor.org>
Subject: Re: [Cfrg] RFC 5742 conflict review for draft-dolmatov-kuznyechik
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Feb 2016 14:26:34 -0000

I concur with ‎Yoav. There is no conflict that I see. This RFC can be published.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Yoav Nir
Sent: Monday, February 1, 2016 08:56
To: Simon Josefsson
Cc: cfrg@irtf.org; Nevil Brownlee
Subject: Re: [Cfrg] RFC 5742 conflict review for draft-dolmatov-kuznyechik


> On 1 Feb 2016, at 3:09 PM, Simon Josefsson <simon@josefsson.org> wrote:
> 
> I believe that publishing the document below would conflict with ongoing
> work in the IETF to provide secure block ciphers that we can use on the
> Internet. It is not in the best interest of the IETF nor the Internet
> at large to publish RFCs of national ciphers if there is no immediate
> desire to use them in Internet protocols.

Hi.

There definitely is a desire to use this cipher. True, all potential users come from the same country, but that should not be blocking.

As a vendor, we often get a request to provide an IPsec and/or TLS implementation with GOST ciphers, and this is the new GOST cipher.

OTOH there is no RFC describing AES either. We usually point to a NIST document. Similarly, there are GOST documents describing kuznyechik. They are even referenced by the draft. So I’m not sure what this draft is supposed to accomplish. Is it merely an English translation? Regardless, this is an algorithm that is going to be used on the Internet and documenting it is a good thing. I don’t see how this interferes with our goal or providing secure block and streamish ciphers.

Yoav