Subject: Re: [Cfrg] CFRG side meeting on re-keying in Chicago

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Fri, 7 Apr 2017 08:42:39 +0300

Dear colleagues,

Sending you a follow-up of our CFRG side meeting at IETF 98, on Thursday,
the 30-th of March, dedicated to the process of development of a CFRG
document on re-keying (draft-irtf-cfrg-re-keying
<https://datatracker.ietf.org/doc/draft-irtf-cfrg-re-keying/>).

The current version of the document is draft-irtf-cfrg-re-keying-01
<https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-01>, it addresses
some first concerns, but is still at quite an early stage, a large number
of new comments and proposals have been received, so the discussion was
needed - and it was the aim of the CFRG side meeting in Chicago at IETF 98.

The following members of CFRG participated in the meeting: Scott Fluhrer,
Sean Leonard (part of the meeting), Yoav Nir, Paul Hoffman, Quynh Dang,
Dorothy Cooley, Alexey Melnikov (part of the meeting), Jim Schaad, Daniel
Fox Franke, Russ Housley, Maksim Kollegin, Stanislav Smyshlyaev.

The received considerations were divided into three parts:
1) issues of the scope and aims of re-keying, declared in the document;
2) recommendations and guidelines in the document for choosing certain
mechanisms for designed protocols and solutions;
3) mechanisms themselves: a list of defined mechanisms and issues of their
descriptions.

1)

The scope and aims were defined according to the comments of Scott Fluhrer,
Evgeny Alekseev and Russ Housley:
a) additional side channel resistance (against DPA or EMI style attacks);
b) PFS security regarding segments of encryption process;
c) lightweight cryptography, usage of ciphers with 32-bit and 64-bit
blocks, (additional issues due to combinatorial problems - bithday paradox
on outputs of basic block cipher permutation);
d) additional security against possible future attacks on the used ciphers
(by limiting the volume of plaintext-ciphertext pairs collected by and
adversary) - as a safety margin. Important notice: This MUST NOT be used as
a method to prolongate life of ciphers that are already known to be
vulnerable.

There also was a discussion on possible connection with post-quantum
security (Paul Hoffman, Scott Fluhrer, Stanislav Smyshlyaev):
Question: Can some post-quantum security issues  for symmetric crypto (i.e.
related to Grover's algorithm) solved by re-keying?
Answer: No, since the reduction of security caused by Grover's algorithm is
not connected with a size of plaintext transformed by a cipher - only a
negligible (sufficient for key uniqueness) material is needed for Grover's
algorithm - and the aim of re-keying is to limit a size of plaintext
transformed on one key.

Question: Which reasons remain when we are treating block ciphers with
large block sizes, e.g. ChaCha20?
Answer: The combinatorial problems become unimportant, but all other
remain: side-channel resistance, PFS, security margin.

2)

The proposal of Russ Housley (accepted at the meeting): to base the text of
recommendations in the document for choice of a re-keying technique
(external/internal) on the following frame: external re-keying is chosen on
a protocol level independently of a block cipher and a block cipher mode,
while an internal re-keying is chosen linked to a block size (of a used
cipher) and block cipher mode of operation.

The proposal of Daniel Franke (accepted at the meeting): to add a text
about advantages and disadvantages of various types of re-keying based on
Seoul CFRG (IETF 97) slides.

The proposal of Dmitry Belyavsky and Daniel Franke (accepted at the
meeting): to provide sample cases (working examples or toy examples) for
choosing one or another type of re-keying for the protocols. The question
is not about test vectors (though they also must be added to the document),
but about illustrating guidelines on choosing re-keying variants for end
protocols.

Question: Which examples should we choose?
Answer: For external serial mechanisms a great working example of TLS 1.3
Key Update exists. For other mechanisms the question must be considered.

Question: Should we change the order of chapters such that the main part of
recommendations would be given before the description of specific
mechanisms.
Answer: Yes, otherwise now the document has to be read starting from the
end.

Question: Should we consider related questions for stream ciphers?
Answer: No. Only for block ciphers in various modes (including counter
mode, of course).

3)

The proposal based on considerations of Maksim Kollegin (accepted at the
meeting): to add explicit text about the principles of choice of constants
for internal re-keying CTR mode (preventing collisions of blocks of
transformed key and block cipher permutation inputs).

The proposal of Dorothy Cooley (accepted at the meeting): to write, what
ACPKM stands for.

The proposal based on considerations of Russ Housley (accepted at the
meeting): to add clarifications about advantages and disadvantages of usage
of the same primitives for re-keying: if we use different primitives, we
separate keys used for data encryption and for supplementary operations
(which can be important to prevent leaking data protection keys through
additional APIs, e.g. in HSMs), on the other hand, it allows not to add
additional circuits/subroutines in implementations (and use the same
primitive implementations for all processes).

The proposal of Daniel Franke (accepted at the meeting): when choosing
constants for internal re-keying, consider only lengths that are multiples
of 8. In this case we can cardinally simplify the methods of constructing
constants.

Question: Which principles should we use when choosing the exact
constructions?
Answer: For each type we should choose one, not more. The current number of
construction is OK, but some could be changed, e.g. the external block
cipher based one. HKDF for external hash-based is OK.

Question: Which KDF, based on the block ciphers, should be chosen?
Answer: Regarding the security issues, they are quite similar, thus in the
current draft the primitives from the paper of Abdalla and Bellare are
described. The question to consider remains: should we change it for
something else (e.g. for some standardized primitive)?

Question: Shay Gueron suggested adding the DeriveKey construction from the
AES-GCM-SIV paper. Should we?
Answer: For now we don't see the arguments for this option.

A fruitful discussion about the modes for internal re-keying took place,
the final answer is based on the considerations of Scott Fluhrer, Yoav Nir,
Jim Schaad, Daniel Franke, Dorothy Cooley and Russ Housley.
Question: Should we leave internal constructions for all modes (including
CBC, CFB, etc.) or only for CTR and GCM?
Answer: We are writing the paper for the future protocols, not for the
existing, so let's consider primarily CTR and GCM - and also add CCM. CBC
is widely used, so we cannot ignore it, but maybe it's better be done as a
separate comment, not as a separate definition of a construction. For
internal modes with a master key a construction is not so linked to a
specific mode (cf. internal ACPKM constructions without master key for
CTR/GCM), so it won't be too difficult.

The work on the document will be continued according to the decisions made
during the discussion.

Best regards,
Stanislav V. Smyshlyaev, Ph.D.,
Head of Information Security Department,
CryptoPro LLC

2017-03-29 23:47 GMT+03:00 Stanislav V. Smyshlyaev <[email-masked]>:

> Dear IETF 98 attendees,
>
> Just a reminder that tomorrow (Thursday, 30th of March) at 10:30 we'll
> have a CFRG side meeting in Bianco room (3rd floor, IESG Breakout room).
>
> Please come if you have any considerations or thoughts about the topic of
> re-keying/key update/KDFs etc. The CFRG document on re-keying is at quite
> early stage currently, all your opinions and proposals are highly wanted.
>
> The current version of the document is the following: https://
> datatracker.ietf.org/doc/html/draft-irtf-cfrg-re-keying-01.
>
> Best regards,
> Stanislav Smyshlyaev
>
>
> 2017-03-25 20:21 GMT+03:00 Alexey Melnikov <[email-masked]>:
>
>> Dear CRFG participants,
>> While CFRG is not meeting in Chicago, there will be a 1 hour design-type
>> meeting to talk about re-keying. Below is information about this meeting:
>>
>> When: On Thursday, March 30th, 10:30am-11:30am
>>
>> Where: BIANCO room of the meeting hotel (3rd Floor). This is IESG
>> Breakout Room.
>>
>>
>> Should the re-keying discussion finish early, other CFRG related topics
>> may be discussed. If you have a topic, please reply to this email or to
>> me directly.
>>
>> Thank you,
>> Alexey, as a CFRG co-chair.
>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>
>