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

Russ Housley <> Thu, 08 June 2017 21:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4399C129508 for <>; Thu, 8 Jun 2017 14:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OZM4Zi8PThZ1 for <>; Thu, 8 Jun 2017 14:39:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7215E1294FA for <>; Thu, 8 Jun 2017 14:39:33 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD6173004B7 for <>; Thu, 8 Jun 2017 17:39:32 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id b0twL5_4wczw for <>; Thu, 8 Jun 2017 17:39:31 -0400 (EDT)
Received: from new-host-6.home ( []) by (Postfix) with ESMTPSA id E27693003FE for <>; Thu, 8 Jun 2017 17:39:31 -0400 (EDT)
From: Russ Housley <>
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: <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-re-keying-02.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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


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/