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

[Russ Housley <[e-mail]>]

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/