Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-xmss-hash-based-signatures-06.txt

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 7 Sep 2016 12:47:54 +0000

Hi everyone,

Now that the CFRG holiday season is over, the chairs are ready to come
back to the problem-ette of how to explain to readers of our post-quantum
IDs what confidence can be placed in them.

A few people (Stephen Farrell, Andreas Huelsing, Watson Ladd), have been
working offlist to wordsmith some text. The current proposal for inclusion
in draft-irtf-cfrg-xmss-hash-based-signatures-06.txt (but which also has
implications for other, future CFRG documents) can be found immediately
below:

General:

"All post-quantum algorithms documented by CFRG are today
considered ready for experimentation and further engineering
development (e.g. to establish the impact of performance and sizes
on IETF protocols). However, at the time of writing, we do not have
significant deployment experience with such algorithms.

Many of these algorithms come with specific restrictions, e.g.
change of classical interface or less cryptanalysis of proposed
parameters than established schemes. CFRG has consensus that all
documents describing post-quantum technologies include the above
paragraph and a clear additional warning about any specific restrictions,
especially as those might affect use or deployment of the specific scheme.
That guidance may be changed over time via document updates."

Addition for XMSS:

"CFRG consensus is that we are confident in the cryptographic security
of the signature schemes described in this document against
quantum computers, given the current state of the research
community's knowledge about quantum algorithms. Indeed, we are
confident that the security of a significant part of the Internet
could be made dependent on the signature schemes defined in this
document, if developers take care of the following.

In contrast to traditional signature schemes, the signature schemes
described in this document are stateful, meaning the secret key
changes over time. If a secret key state is used twice, no cryptographic
security guarantees remain. This is a new property that most
developers will not be familiar with and requires careful handling of
secret keys. Developers should not use the schemes described here
except in systems that prevent the reuse of secret key states."

Please send your comments about this text on-list.

Regards

Kenny
(for the chairs)