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

Yaron Sheffer <yaronf.ietf@gmail.com> Wed, 08 November 2017 15:45 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24359127A91 for <cfrg@ietfa.amsl.com>; Wed, 8 Nov 2017 07:45:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7owSuKUbabn for <cfrg@ietfa.amsl.com>; Wed, 8 Nov 2017 07:45:16 -0800 (PST)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5D9127869 for <cfrg@irtf.org>; Wed, 8 Nov 2017 07:45:15 -0800 (PST)
Received: by mail-pf0-x22d.google.com with SMTP id b6so1740783pff.10 for <cfrg@irtf.org>; Wed, 08 Nov 2017 07:45:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=dqRA4M05TuJCev/x6v1NUI9Q7MhMQhbyOfC1LPJDpT4=; b=FqYxJB65V85KPXV8tcnf2g1dSa/gp8PpOkBUCUAkzIMXz+WEd+C/yKJ+j0dl9PbWIs S8jU8lgtyK1Hh96i+sF2mZlfxx13WErIhvxzPV7ivKVBe5NR4kLrmIbABKzc+sZQp8L5 L+ViV+6dfDPecAP3Ueq6B2y+OfXwFP+0sabWOaZwoZ+fOJ4UkYD0wfoYAk2uM8OArSu2 7cpVGFSp4t7WEFr5vhfG36nH4+kAjlvirBBnT4PcEbjeuVPDavvTLCA060rSqUI/vyjK R+w7eLxxF8ToGDtN/M6WZSeqQWynvYLtZpYBawKx9m2vsBvMNcp7tyAdjn1YorhrDYkz i6qQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=dqRA4M05TuJCev/x6v1NUI9Q7MhMQhbyOfC1LPJDpT4=; b=V3XCs2t8MxrvVT1paL2QSDR1uttcQ5RBPEef7lGS917V2por3iSskytwa+ixgzC4jo sz0fFp76pNvlQV1Q/Kn2jND9EC/waNcS1gc8ii5fqsTa+UrzyClsoAWOkVzv4nj0dMA6 g47COIdd0VV7/ghZkTTSdvBo7PIxDxw248r6/sMww0ZpE0v+U164CplCTVksm3iWpFM3 eGj3VTIYpF0iqyhCflbTdtvasF9ojg5gx62+P1Kub1WLuCDLfglGno5BsZq5Si+eE/M8 HPMVueV/gnNMiJiLUnvF6Ap0oZ28XWEE+3IRVEfbMeL2aYiVPZ3pekj08b80lsVLT2gw vJiw==
X-Gm-Message-State: AJaThX6XXXn53004B0u8u02WrT7kR+6QiAp0mZYvwyghkaw8JpP4eUG8 u/iNL4eMILQ/9Mz7pYmZcPrK1VOp
X-Google-Smtp-Source: ABhQp+RhxYaWYJKIEZGL0GaBtD0WDZJR+W/zi43hyGB3NOOI8PQoJJXWRnft57ea0buWmCV5y0G7+Q==
X-Received: by 10.101.88.203 with SMTP id e11mr862485pgu.173.1510155915035; Wed, 08 Nov 2017 07:45:15 -0800 (PST)
Received: from [172.18.129.55] (bzq-202-11.red.bezeqint.net. [212.179.202.11]) by smtp.gmail.com with ESMTPSA id g16sm8125687pgn.43.2017.11.08.07.45.12 for <cfrg@irtf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 07:45:14 -0800 (PST)
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: cfrg@irtf.org
Message-ID: <6a0c609b-2986-2498-1ad6-38689dcdaa5f@gmail.com>
Date: Wed, 8 Nov 2017 17:45:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/xPDbv5miygrL1ycsw9uvGNBC6QY>
Subject: [Cfrg] Review of draft-irtf-cfrg-re-keying-08
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Nov 2017 15:45:18 -0000

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 referencehttps://eprint.iacr.org/2017/697.pdf  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.