Re: [Cfrg] Review of draft-irtf-cfrg-re-keying-08

"Stanislav V. Smyshlyaev" <> Wed, 08 November 2017 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E24A12871F for <>; Wed, 8 Nov 2017 08:26:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yt33T1d4pZoa for <>; Wed, 8 Nov 2017 08:26:41 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0959C1286D6 for <>; Wed, 8 Nov 2017 08:26:41 -0800 (PST)
Received: by with SMTP id v137so4042550qkb.1 for <>; Wed, 08 Nov 2017 08:26:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6HZnFcTXht2UdyJQmry+GJNxmZ5gLGP4O9bxIiLT64c=; b=P4fELJTClasreqBfX66nIl/QgYf35lHAs8aLtc1ta9v6gsePkWgAOZXeDtOULMmfcT JKhytevDWSFmMGYzV/osO1tvJlC0vi0cDLY9qvE07U7Pk43S0LVQKkoIXq9clluctmIi ltWuf3gj/5ZIGMrAUVr3os4d0tOQURfTbAz5DL/pSFyAKV3mQDvhO18G0L/IqXNHflAE 7PJROIhp4XspAPS96fmnaye+I7JuIyFj1Gf/33ZVtBzUVeirQk72Nu5tmmv4eQ7j3/9L 92PVIw1OCnlb6zvMZtQLcfOxRkl+XEwNeePtOCaKZUIUEYjQbOY5CVuiMIZCTzgBnMys cFkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6HZnFcTXht2UdyJQmry+GJNxmZ5gLGP4O9bxIiLT64c=; b=lVWzzB4OfDHCEZCtjV4deDq0reYG5/2dNZx3PnaOXwQYCITcg1f4QRcEdmOHvRURvZ gGTo+hN3le7T5bJGZ/L6EDywb47Gmh7Gk5A8zaOysL42j7MC1l/oReIW0YxpjOwp/dHQ FCUX0wpteid1W/kFRBW69QoaMP6FrENjmaCtihxtzndUXeQDj2t3LvUg7Q80oaz6LE+0 1dbDsIk6212TuRCpBNCn/ZtkFCQUTN+asWAq/QqzLqsVwxcR+CN19pD20CszQ/pacxQY 9fGTr6RvyK79AmMXlxb+9/XRt+yy/7fvNJEGvM1U/SODRgmVxHyYfkKmSt5KT1K1fcCj nGuA==
X-Gm-Message-State: AJaThX4X0ensLp83oT9ySGVp+TaKI6sjzbTBC32d1GFCNH5Ci60Gg7+2 WeqsT7YLBJd+hq4a6d5UUgg3gtLp7oSTOGODg+k=
X-Google-Smtp-Source: ABhQp+SpK0NNtO3HPRKAZEb74UFPUupOXQIMCLDc804Ybi6hvBpJ9NMMeExTEsnMUenFb/GppWEFsrHmSZzIEEkUHOs=
X-Received: by with SMTP id e184mr1633635qkb.126.1510158400156; Wed, 08 Nov 2017 08:26:40 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 8 Nov 2017 08:26:39 -0800 (PST)
In-Reply-To: <>
References: <>
From: "Stanislav V. Smyshlyaev" <>
Date: Wed, 08 Nov 2017 19:26:39 +0300
Message-ID: <>
To: Yaron Sheffer <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="001a114a7036fefb5c055d7b260b"
Archived-At: <>
Subject: Re: [Cfrg] Review of draft-irtf-cfrg-re-keying-08
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: Wed, 08 Nov 2017 16:26:43 -0000

Dear Yaron,

Thank you very much for your efforts - most of your comments are very
reasonable and I believe that addressing them will make the resulting
document better.

Some of the issues (e.g. the mix-in entropy for the cases of long-term keys
stored inside HSMs) seem to be complex enough for creating separate
documents to address them, but, of course, it will be good for the current
I-D if we add considerations related to them.

After receiving concerns and recommendations of the second Crypto Panel
review and keeping in mind additional questions that have been raised
recently (related to Peter Alexander's I-D), I'll prepare a summary of the
things to be done before finishing the document. I hope that I'll also
manage to give such a summary in my talk at CFRG meeting during IETF 100.

Best regards,


2017-11-08 18:45 GMT+03:00 Yaron Sheffer <>:

> Summary
> I think the document is not ready to be published yet, for the following
> reasons:
> First, it is very heavy reading, with important details buried between
> mountains of pseudo-code and analysis. I would recommend to add a 2-page
> summary at the top of the document, describing the proposed solutions and
> their applicability. Maybe Sec. 4 could be tweaked into this form if you
> added forward references to the specific proposed mechanisms, but then the
> section would still be very long.
> Second, this document is a problematic hybrid of common techniques for
> "external" re-keying, and original cryptography for "internal" re-keying
> (where a reference to the work/proof is definitely needed). Readers who
> approach the document expecting a survey because of the very generic title
> will be surprised. Assuming this is intended to be a survey of related
> techniques, references to the literature are needed, and I would expect
> additional techniques to be mentioned, even if briefly.
> Lastly, I would expect more clarity on the interaction of the re-keying
> mechanisms with security protocols and operating systems. Security
> protocols and operating systems both allow to refresh keys with new
> entropy. In addition, HSMs (and related technologies, such as security
> enclaves) can help to achieve better forward secrecy using asymmetric
> cryptography than the techniques described here. I would also suggest to
> mention another important use case for symmetric key re-keying: encryption
> of data at rest.
> Please note that this document includes original cryptography, and, not
> being a cryptographer, I am unable to comment on its security.
> This review was written at the request of the CFRG Crypto Panel. I have
> benefited from a lengthy discussion with the draft's author, Stanislav
> Smyshlyaev, and I would like to thank him for that.
> Details
> * Abstract: you use the terms "internal" and "external" which are neither
> defined here nor very common, so I don't think they belong in the abstract.
> * "Key lifetime" often means something else, the actual time (e.g. months)
> after which the user is procedurally obliged to replace a key. So let's say
> that this is/our/definition of the term.
> * 2^(n/2) where n is?
> * "the total size of the processed plaintext" - often the limitation is on
> the number of encryptions (e.g. number of packets encrypted) rather than
> total size, e.g. because of nonce reuse. And this is the exact opposite of
> the rectangle analogy, which implies that the fixed value is the total
> number.
> * Introduction: please mention if these solutions also apply to encryption
> of data at rest, in addition to network protocols.
> * Also, your threat model does not include what is possibly the most
> important threat for many Internet-connected systems: a time-limited but
> complete breach of the system. If these approaches are useless under this
> threat and only external renegotiation with forward secrecy is effective,
> fine, but we should say so.
> * Introduction: I suggest that you mention who is the target audience:
> protocol developers? Implementers? Are there cases where these mechanisms
> can be used with no protocol-level changes and therefore can be used
> directly by implementers?
> * Basic Terms: for some of these definitions, an informal explanation
> would help. E.g. Int_s is the interpretation of the string as a binary
> integer.
> * Terms: "section" is a strange name, but I don't have a better
> alternative.
> * "For protocols which allow out-of-order delivery and lost records" -
> these protocols typically include a sequence number which can be used for
> internal rekeying.
> * The "summing up" section includes several assertions that have not been
> explained yet at this point, e.g. about tree-based, hash-based re-keying.
> * Serial (external) constructions: it is unclear to me what are the use
> cases where the serial mechanisms may be preferred.
> * While a proof does not belong in an RFC, the document should
> reference  which contains security
> proofs, at least for some variants of ACPKM.
> * 6.2.1: you lost me in the arithmetic. Are we assuming a certain block
> size for the cipher here?
> * "It allows to prevent collisions of block cipher permutation inputs in
> cases of key transformation and message processing" - this text is
> extremely opaque.
> * 6.2.3: as far as I remember, GCM is defined even when the last block is
> not a multiple of 16 bytes. So I think this mode should also handle this
> case. At least GHASH appears not to do that. And I think the same applies
> to the CTR mode above.
> * I'm not sure I understand the notion of a "master key" in this context,
> and maybe it is not explained well. ISTM that the difference between ACPKM
> and ACPKM-Master is that one is serial (K is used for the first section,
> and then repeatedly processed to produce a sequence of keys) whereas the
> other one is "parallel", and does not use K directly. But K is obtained the
> same way from the network protocol, so it doesn't make sense to me to call
> it "master key" only in the parallel case.
> _______________________________________________
> Cfrg mailing list