Re: [Cfrg] I-D Action: draft-irtf-cfrg-re-keying-02.txt

Russ Housley <housley@vigilsec.com> Thu, 08 June 2017 21:39 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4399C129508 for <cfrg@ietfa.amsl.com>; Thu, 8 Jun 2017 14:39:35 -0700 (PDT)
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] 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 OZM4Zi8PThZ1 for <cfrg@ietfa.amsl.com>; Thu, 8 Jun 2017 14:39:33 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7215E1294FA for <cfrg@ietf.org>; Thu, 8 Jun 2017 14:39:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DD6173004B7 for <cfrg@ietf.org>; Thu, 8 Jun 2017 17:39:32 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id b0twL5_4wczw for <cfrg@ietf.org>; Thu, 8 Jun 2017 17:39:31 -0400 (EDT)
Received: from new-host-6.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E27693003FE for <cfrg@ietf.org>; Thu, 8 Jun 2017 17:39:31 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 8 Jun 2017 17:39:31 -0400
References: <149667340139.3152.10556340180920549215@ietfa.amsl.com>
To: cfrg@ietf.org
In-Reply-To: <149667340139.3152.10556340180920549215@ietfa.amsl.com>
Message-Id: <89AFF43D-EFE7-4D7F-8ECE-877A4BEBD546@vigilsec.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/ilv4WrhBTPZ1m786-0CgYHdqbAE>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-re-keying-02.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
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: Thu, 08 Jun 2017 21:39:35 -0000

I have a few comments on the most recent version of this document.

Section 1: Please describe parallel and serial re-keying mechanisms in the introduction.

Section 1: I think we need to say more about internal re-key when it is first introduced.  I suggest:

   This specification presents two approaches that extend the key
   lifetime for a single symmetric key while avoiding renegotiation: 
   external and internal re-keying.  External re-keying is performed by a
   protocol, and it is independent of block cipher, key size, and mode.
   Internal re-keying is built into the mode, and it depends heavily on
   the properties of the block cipher and key size.

Section 1, Last paragraph: Please separate the ideas here.  First, TLS 1.3 is an example of a protocol with external re-key.  Second, there is a discussion of the benefits of re-key.  The first belongs elsewhere.

Section 4 says:

   . . .   External re-
   keying approach is recommended for usage in protocols that process
   quite small messages. . . . 

It is obvious that the message size can exceed L.  That said, external re-keying is also very useful when there are lots of messages or the protocol has a way to break a very large message into manageable chunks.  Obviously, TCP breaks a very large stream into many manageable chunks.

Section 4, first item number 3 says:

   . . .  provides forward and backward security of session keys . . .

This is only true if the previous traffic keys are securely deleted by all parties that have the keys.

Section 5, bottom of page 8:  Wouldn’t it be cleaner to say:

   L = min(L1, L2)
   q = min(q1, q2)
   q*m <= L



Nits:

Please use figure numbers and captions on the illustrations.

Section 1: s/&#1057;/C/

Section 4: s/Homever/However/

Section 4: s/it almost does not affect performance/minimal impact on performance/

Section 4: s/sessin keys/session keys/

Section 4: s/always have an access/always has access/