Re: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09

Valery Smyslov <svan@elvis.ru> Wed, 25 December 2019 18:44 UTC

Return-Path: <svan@elvis.ru>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4EF1200A1; Wed, 25 Dec 2019 10:44:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 AZGoerrZBrVP; Wed, 25 Dec 2019 10:44:17 -0800 (PST)
Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D42812002E; Wed, 25 Dec 2019 10:44:17 -0800 (PST)
Received: from kmail2.elvis.ru ([93.188.44.210]) by akmail.elvis.ru with esmtp (Exim 4.89) (envelope-from <svan@elvis.ru>) id 1ikBdm-0007y3-9P; Wed, 25 Dec 2019 21:44:14 +0300
Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail2.elvis.ru with esmtp (Exim 4.89) (envelope-from <svan@elvis.ru>) id 1ikBdl-0001H0-BP; Wed, 25 Dec 2019 21:44:14 +0300
Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Wed, 25 Dec 2019 21:44:10 +0300
Received: from chichi (10.100.100.5) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Wed, 25 Dec 2019 21:44:07 +0300
From: Valery Smyslov <svan@elvis.ru>
To: 'Watson Ladd' <watsonbladd@gmail.com>, 'Uri Blumenthal' <uri@mit.edu>
CC: 'Valery Smyslov' <valery@smyslov.net>, ipsec@ietf.org, last-call@ietf.org, 'secdir' <secdir@ietf.org>, draft-ietf-ipsecme-qr-ikev2.all@ietf.org
References: <003901d5bb48$cfc21460$6f463d20$@smyslov.net> <8A4F97F4-723E-41C8-B4F6-C6D65F0BC848@mit.edu> <CACsn0cmPzNZ55XExNPJ5FXrCWcVY+aXTD7E_+MnaRV_bgcuRyw@mail.gmail.com>
In-Reply-To: <CACsn0cmPzNZ55XExNPJ5FXrCWcVY+aXTD7E_+MnaRV_bgcuRyw@mail.gmail.com>
Date: Wed, 25 Dec 2019 21:44:05 +0300
Message-ID: <007b01d5bb53$48c557f0$da5007d0$@elvis.ru>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01D5BB6C.6E143DA0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHdvvqKSyXWSys4i9wLZip4/JKSjgI7xNqsAbHYPj2nm7dRkA==
Content-Language: ru
X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru
X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru
X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST
X-KLMS-Rule-ID: 1
X-KLMS-Message-Action: clean
X-KLMS-AntiSpam-Status: not scanned, disabled by settings
X-KLMS-AntiPhishing: Clean, bases: 2019/12/25 18:17:00
X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2019/12/25 14:37:00 #14886745
X-KLMS-AntiVirus-Status: Clean, skipped
X-Spam-Scanner: Rspamd work in akmail.elvis.ru, WHITELIST
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/TEVYVnXY8osJz9kMAzJoCDCiJ3U>
Subject: Re: [secdir] Secdir last call review of draft-ietf-ipsecme-qr-ikev2-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Dec 2019 18:44:20 -0000

Do you mean the post-quantum cryptography competition (https://csrc.nist.gov/Projects/post-quantum-cryptography)? 

 

That's why I felt confused. The draft isn't concerned with any post-quantum cryptography stuff,

it uses only well-studied methods of classical cryptography. I don't think this particular 

competition is relevant here.

 

However, taking into consideration Grover's algorithm, it seems that 128 bit level is the maximum

available for the current off-the-shelf crypto algorithms (I'm not aware of any widely used cipher with key 

length more than 256 bit).

 

Regards,

Valery.

 

 

I'm talking about the ongoing NIST quantum cryptography competition, which targets at the lowest level security equivalent to AES-128.

 

On Wed, Dec 25, 2019 at 10:24 AM Uri Blumenthal <uri@mit.edu> wrote:

NIST produces standards and recommendations. US government organizations and companies doing business with them are usually required to comply. Organizations and businesses (both US and non-US) that are not bound by US regulations, often pay attention to what NIST recommends. 

 

To repeat myself, it mages sense to add reference to the NIST levels, even if Watson doesn't insist. ;-)





On Dec 25, 2019, at 12:29, Valery Smyslov <valery@smyslov.net> wrote:

 

On Wed, Dec 25, 2019 at 3:57 AM Uri Blumenthal < <mailto:uri@mit.edu> uri@mit.edu> wrote:

NIST standards are mandatory for a subset of US citizens. But enough of businesses outside the US pay attention to what NIST says to make adding the reference relevant and useful.

 

It's not about standards, it's about the competition and the relevant security level definitions. Not that I feel strongly about it, just a suggestion..

 

          Then I'm a bit confused. What competition do you mean? 

 

          Regards,

          Valery.

 

 

 

On Dec 25, 2019, at 01:52, Valery Smyslov <svan@elvis.ru> wrote:

 

Hi Watson,

 

thank you for spending your time on this review in Christmas Eve.

 

The capitalization issue has been already noticed and fixed.

 

I’m not sure the draft should mention NIST levels, because 

they are relevant mostly for US customers. I think that 

generic recommendations on key sizes are more appropriate

for this document.

 

Regards,

Valery.

 

Damn misclick. I meant With Nits.

 

On Tue, Dec 24, 2019 at 8:02 PM Watson Ladd via Datatracker <noreply@ietf.org> wrote:

Reviewer: Watson Ladd
Review result: Not Ready

Twas the night before Christmas
when all through the house
someone was desperately trying to get a review done on time.

I didn't see anything wrong per se in the draft itself, but I found the
capitalization of quantum computer an odd choice. IKEv2 is a complicated
protocol, and I am not 100% sure that this draft does what we want it to: It
would be great if someone could check very carefully in some symbolic model,
ala what has been done in TLS. The guidance on sizes seems to rule out NIST
level 1, but not any higher levels: might be worth calling out this explicitly.

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



-- 

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

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



-- 

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



-- 

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