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

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 <housley@vigilsec.com>:

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