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

From: [email-masked]
Date: Mon, 05 Jun 2017 07:36:41 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Crypto Forum of the IETF.

        Title           : Re-keying Mechanisms for Symmetric Keys
        Author          : Stanislav Smyshlyaev
	Filename        : draft-irtf-cfrg-re-keying-02.txt
	Pages           : 46
	Date            : 2017-06-05

Abstract:
   If encryption is performed under a single key, there is a certain
   maximum threshold amount of data that can be safely encrypted.  This
   amount is called key lifetime.  This specification contains a
   description of a variety of methods to increase the lifetime of
   symmetric keys.  It provides external and internal re-keying
   mechanisms based on hash functions and on block ciphers that can be
   used with such modes of operations as CTR, GCM, CCM, CBC, CFB, OFB
   and OMAC.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-re-keying/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-02
https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-re-keying-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-re-keying-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Russ Housley <[email-masked]>
Date: Thu, 8 Jun 2017 17:39:31 -0400

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/

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Tue, 20 Jun 2017 15:41:57 +0300

Dear colleagues,

We've posted an updated version of the draft (see
https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-03), in which we've
tried to address received concerns (thanks again for all of them, by the
way!).
Almost all the comments were fully taken into account, with the following
comments:
1. > 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.
We completely agree with this comment, but instead of separating these
ideas, we deleted the first sentence, since the reference to TLS 1.3 is
provided below.
2. > 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.
We added this clarification to Security Considerations section.
3. >  Wouldn’t it be cleaner to say: L = min(L1, L2), q = min(q1, q2), q*m
<= L
We added this explanation, but we did not remove the old text, because it
looks important to show that (as L1 is usually much less than L2) the key
lifetime can be greatly increased, because re-keying lets us to forget
about the "side-channel limitation" L1.

Best regards,
Stanislav

2017-06-09 0:39 GMT+03:00 Russ Housley <[email-masked]>:

> 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-
> 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.
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>