Skip to main content

Randomness Improvements for Security Protocols
draft-irtf-cfrg-randomness-improvements-14

Revision differences

Document history

Date Rev. By Action
2020-10-07
14 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-10-01
14 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-09-01
14 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-08-20
14 (System) RFC Editor state changed to EDIT
2020-08-19
14 (System) IANA Action state changed to No IANA Actions from In Progress
2020-08-19
14 (System) IANA Action state changed to In Progress
2020-08-19
14 Colin Perkins IRTF state changed to Sent to the RFC Editor from In IESG Review
2020-08-19
14 Colin Perkins Sent request for publication to the RFC Editor
2020-08-19
14 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-08-19
14 Christopher Wood New version available: draft-irtf-cfrg-randomness-improvements-14.txt
2020-08-19
14 (System) New version accepted (logged-in submitter: Christopher Wood)
2020-08-19
14 Christopher Wood Uploaded new revision
2020-07-14
13 (System) IANA Review state changed to IANA OK - No Actions Needed
2020-07-14
13 Sabrina Tanamal
(Via drafts-eval@iana.org): IESG/Authors/IRTF Chair:

The IANA Functions Operator has reviewed draft-irtf-cfrg-randomness-improvements and has the following comments:

We understand that this document doesn't require any …
(Via drafts-eval@iana.org): IESG/Authors/IRTF Chair:

The IANA Functions Operator has reviewed draft-irtf-cfrg-randomness-improvements and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-07-13
13 Colin Perkins Awaiting IESG conflict review.
2020-07-13
13 Colin Perkins IRTF state changed to In IESG Review from Waiting for IRTF Chair
2020-07-13
13 Colin Perkins IETF conflict review initiated - see conflict-review-irtf-cfrg-randomness-improvements
2020-07-12
13 Colin Perkins Will send for IESG conflict review.
2020-07-12
13 Colin Perkins IRTF state changed to Waiting for IRTF Chair from Waiting for Document Shepherd
2020-06-24
13 (System) Revised ID Needed tag cleared
2020-06-24
13 Christopher Wood New version available: draft-irtf-cfrg-randomness-improvements-13.txt
2020-06-24
13 (System) New version accepted (logged-in submitter: Christopher Wood)
2020-06-24
13 Christopher Wood Uploaded new revision
2020-06-23
12 Colin Perkins Completed IRSG final poll. Some minor comments to address.
2020-06-23
12 Colin Perkins Tag Revised I-D Needed set.
2020-06-23
12 Colin Perkins IRTF state changed to Waiting for Document Shepherd from In IRSG Poll
2020-06-23
12 Colin Perkins Closed "IRSG Approve" ballot
2020-06-19
12 Stanislav Smyshlyaev [Ballot comment]
I am one of the authors.
2020-06-19
12 Stanislav Smyshlyaev [Ballot Position Update] New position, Recuse, has been recorded for Stanislav Smyshlyaev
2020-06-19
12 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Recuse
2020-06-19
12 Alexey Melnikov [Ballot comment]
I am the document shepherd.
2020-06-19
12 Alexey Melnikov [Ballot Position Update] New position, Recuse, has been recorded for Alexey Melnikov
2020-06-04
12 Mallory Knodel [Ballot Position Update] New position, Yes, has been recorded for Mallory Knodel
2020-05-31
12 Dirk Kutscher [Ballot Position Update] New position, No Objection, has been recorded for Dirk Kutscher
2020-05-27
12 Mat Ford [Ballot Position Update] New position, No Objection, has been recorded for Mat Ford
2020-05-27
12 David Oran [Ballot comment]
I read the document fairly throughly and although not a security expert, I found no problems.
2020-05-27
12 David Oran [Ballot Position Update] New position, Yes, has been recorded for David Oran
2020-05-27
12 Mirja Kühlewind
[Ballot comment]
One minor editorial comments: I'm not sure I full understand the term "participants" in the abstract. Maybe there is better word?

And further …
[Ballot comment]
One minor editorial comments: I'm not sure I full understand the term "participants" in the abstract. Maybe there is better word?

And further I would recommend to split reference up in normative and informational, given it's clear that not all listed reference are normative to understand this document.
2020-05-27
12 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2020-05-26
12 Jianfei(Jeffrey) HE
[Ballot comment]
The document is generally clear in its objective and methods. One comment is on "the length  M" at the 2nd paragraph in section …
[Ballot comment]
The document is generally clear in its objective and methods. One comment is on "the length  M" at the 2nd paragraph in section 3 "Randomness Wrapper". It is not explicitly described how to decide this value.

In RFC 5869, it is stated as below:
"Ideally, the salt value is a random (or pseudorandom) string of the length HashLen.  Yet, even a salt value of less quality (shorter in size or with limited entropy) may still make a significant contribution to the security of the output keying material"

But to the specific application in this draft, it is not sure M chould be almost arbitary, or M =< L, or there are more specific suggestions from best practices.
2020-05-26
12 Jianfei(Jeffrey) HE Ballot comment text updated for Jianfei He
2020-05-26
12 Jianfei(Jeffrey) HE
[Ballot comment]
The document is generally clear in its objective and methods. One comment is on "the length  M" at the 2nd paragraph in section …
[Ballot comment]
The document is generally clear in its objective and methods. One comment is on "the length  M" at the 2nd paragraph in section 3 "Randomness Wrapper". It is not explicitly described how to decide this value.
in RFC 5869, it is stated as below:
"Ideally, the salt value is a random (or pseudorandom) string of the length HashLen.  Yet, even a salt value of less quality (shorter in size or with limited entropy) may still make a significant contribution to the security of the output keying material"
But to this specific application in this draft, it is not sure M chould be almost arbitary or M =< L, or there are more specific suggestions.
2020-05-26
12 Jianfei(Jeffrey) HE [Ballot Position Update] New position, No Objection, has been recorded for Jianfei He
2020-05-26
12 Spencer Dawkins
[Ballot comment]
This seems a fine document. I do have some nits, and questions about BCP14 usage. Do the right thing, of course.

I'm thinking …
[Ballot comment]
This seems a fine document. I do have some nits, and questions about BCP14 usage. Do the right thing, of course.

I'm thinking that the mentions of "Dual_EC_DRBG" and "Debian bugs" may not be meaningful to future readers ("RFCs are forever") in the Abstract without references (which we don't put in Abstracts).

  Randomness is a crucial ingredient for Transport Layer Security (TLS)
  and related security protocols.  Weak or predictable
  "cryptographically-strong" pseudorandom number generators (CSPRNGs)
  can be abused or exploited for malicious purposes.  The Dual_EC_DRBG
                                                      ^^^^^^^^^^^^^^^^
  random number backdoor and Debian bugs are relevant examples of this
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  problem.  An initial entropy source that seeds a CSPRNG might be weak
  ^^^^^^^
  or broken as well, which can also lead to critical and systemic
  security problems.  This document describes a way for security
  protocol participants to augment their CSPRNGs using long-term
  private keys.  This improves randomness from broken or otherwise
  subverted CSPRNGs.
 
Perhaps that sentence could be omitted, since both are mentioned in the Introduction with references?

I know that CSPRNG is expanded in the Abstract, but I'd suggest expaanding it on first use in the text.

  Randomness is a crucial ingredient for TLS and related transport
  security protocols.  TLS in particular uses random number generators
  (generally speaking, CSPRNGs) to generate several values: session
                        ^^^^^^^

I understood

  2.  An adversary Adv with full control of a (potentially broken)
      CSPRNG and able to observe all outputs of the proposed
      construction, does not obtain any non-negligible advantage in
      leaking the private key, modulo side channel attacks.
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^

as saying "without using side channel attacks" - did I get that right? But you might consider being a little less terse than "modulo".

This text
  Let G(n) be an algorithm that generates n random bytes, i.e., the
  output of a CSPRNG.  Define an augmented CSPRNG G' as follows.  Let
  Sig(sk, m) be a function that computes a signature of message m given
  private key sk.  Let H be a cryptographic hash function that produces
  output of length M.  Let Extract(salt, IKM) be a randomness
  extraction function, e.g., HKDF-Extract [RFC5869], which accepts a
  salt and input keying material (IKM) parameter and produces a
  pseudorandom key of L bytes suitable for cryptographic use.  It must
  be a secure PRF (for salt as a key) and preserve uniformness of IKM
  (for details see [SecAnalysis]).  L SHOULD be a fixed length.  Let
  Expand(k, info, n) be a variable-length output PRF, e.g., HKDF-Expand
  [RFC5869], that takes as input a pseudorandom key k of L bytes, info
  string, and output length n, and produces output of n bytes.
  Finally, let tag1 be a fixed, context-dependent string, and let tag2
  be a dynamically changing string (e.g., a counter) of L' bytes.  We
  require that L >= n - L' for each value of tag2.
 
has an interesting mix of normative ("SHOULD"), apparently non-normative ("MUST"), semi-normative ("We require that X"), and asserted ("Let A be X") constraints. Are you sure this variety is necessary? At a minimum, you might consider giving guidance about when an implementer might use variable-length Ls, so that implementers could better understand when it's appropriate to use them.

Is
  Both tags SHOULD be generated such that they never collide with
  another contender or owner of the private key.  This can happen if,
  for example, one HSM with a private key is used from several servers,
  or if virtual machines are cloned.
 
actually a normative SHOULD? If the tags do collide, what happens? (If it's Really Bad, why is this not a MUST?) Is there a reason an implementer would need to ignore this requirement?

I have roughly the same question about

  Tag strings SHOULD be constructed as follows:
              ^^^^^^
 
What happens if they aren't? Why would an implementer need to construct them some other way?

And about

  Recall that the wrapper defined in Section 3 requires L >= n - L',
  where L is the Extract output length and n is the desired amount of
  randomness.  Some applications may require n to exceed this bound.
  Wrapper implementations SHOULD support this use case by invoking G'
                          ^^^^^^
  multiple times and concatenating the results.
 
Wha happens if the implementation doesn't? Why would an implementation need to support this use case some other way?

In this text

  The proposed construction cannot provide any guarantees of security
  if the CSPRNG state is cloned due to the virtual machine snapshots or
  process forking (see [MAFS2017]).  Thus tag1 SHOULD incorporate all
                                                ^^^^^^
  available information about the environment, such as process
  attributes, virtual machine user information, etc.
 
the second sentence looks more like guidance than a normative requirement to me.
2020-05-26
12 Spencer Dawkins Ballot comment text updated for Spencer Dawkins
2020-05-26
12 Spencer Dawkins
[Ballot comment]
This seems a fine document. I do have some nits, and questions about BCP14 usage. Do the right thing, of course.

I'm thinking …
[Ballot comment]
This seems a fine document. I do have some nits, and questions about BCP14 usage. Do the right thing, of course.

I'm thinking that the mentions of "Dual_EC_DRBG" and "Debian bugs" may not be meaningful to future readers ("RFCs are forever") in the Abstract without references (which we don't put in Abstracts).

  Randomness is a crucial ingredient for Transport Layer Security (TLS)
  and related security protocols.  Weak or predictable
  "cryptographically-strong" pseudorandom number generators (CSPRNGs)
  can be abused or exploited for malicious purposes.  The Dual_EC_DRBG
                                                      ^^^^^^^^^^^^^^^^
  random number backdoor and Debian bugs are relevant examples of this
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  problem.  An initial entropy source that seeds a CSPRNG might be weak
  ^^^^^^^
  or broken as well, which can also lead to critical and systemic
  security problems.  This document describes a way for security
  protocol participants to augment their CSPRNGs using long-term
  private keys.  This improves randomness from broken or otherwise
  subverted CSPRNGs.
 
Perhaps that sentence could be omitted, since both are mentioned in the Introduction with references?

I know that CSPRNG is expanded in the Abstract, but I'd suggest expaanding it on first use in the text.

  Randomness is a crucial ingredient for TLS and related transport
  security protocols.  TLS in particular uses random number generators
  (generally speaking, CSPRNGs) to generate several values: session
                        ^^^^^^^

I understood

  2.  An adversary Adv with full control of a (potentially broken)
      CSPRNG and able to observe all outputs of the proposed
      construction, does not obtain any non-negligible advantage in
      leaking the private key, modulo side channel attacks.
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^

as saying "without using side channel attacks" - did I get that right? But you might consider being a little less terse than "modulo".

This text
  Let G(n) be an algorithm that generates n random bytes, i.e., the
  output of a CSPRNG.  Define an augmented CSPRNG G' as follows.  Let
  Sig(sk, m) be a function that computes a signature of message m given
  private key sk.  Let H be a cryptographic hash function that produces
  output of length M.  Let Extract(salt, IKM) be a randomness
  extraction function, e.g., HKDF-Extract [RFC5869], which accepts a
  salt and input keying material (IKM) parameter and produces a
  pseudorandom key of L bytes suitable for cryptographic use.  It must
  be a secure PRF (for salt as a key) and preserve uniformness of IKM
  (for details see [SecAnalysis]).  L SHOULD be a fixed length.  Let
  Expand(k, info, n) be a variable-length output PRF, e.g., HKDF-Expand
  [RFC5869], that takes as input a pseudorandom key k of L bytes, info
  string, and output length n, and produces output of n bytes.
  Finally, let tag1 be a fixed, context-dependent string, and let tag2
  be a dynamically changing string (e.g., a counter) of L' bytes.  We
  require that L >= n - L' for each value of tag2.
 
has an interesting mix of normative ("SHOULD"), apparently non-normative ("MUST"), semi-normative ("We require that X"), and asserted ("Let A be X") constraints. Are you sure this variety is necessary? At a minimum, you might consider giving guidance about when an implementer might use variable-length Ls, so that implementers could better understand when it's appropriate to use them.

Is
  Both tags SHOULD be generated such that they never collide with
  another contender or owner of the private key.  This can happen if,
  for example, one HSM with a private key is used from several servers,
  or if virtual machines are cloned.
 
actually a normative SHOULD? If the tags do collide, what happens? (If it's Really Bad, why is this not a MUST?) Is there a reason an implementer would need to ignore this requirement?

I have roughly the same question about

  Tag strings SHOULD be constructed as follows:
              ^^^^^^
 
What happens if they aren't? Why would an implementer need to construct them some other way?

And about

  Recall that the wrapper defined in Section 3 requires L >= n - L',
  where L is the Extract output length and n is the desired amount of
  randomness.  Some applications may require n to exceed this bound.
  Wrapper implementations SHOULD support this use case by invoking G'
                          ^^^^^^
  multiple times and concatenating the results.
 
Wha happens if the implementation doesn't? Why would an implementation need to support this use case some other way?

In this text

  The proposed construction cannot provide any guarantees of security
  if the CSPRNG state is cloned due to the virtual machine snapshots or
  process forking (see [MAFS2017]).  Thus tag1 SHOULD incorporate all
                                                ^^^^^^
  available information about the environment, such as process
  attributes, virtual machine user information, etc.
 
the second sentence looks more like guidance than a normative requirement to me.
2020-05-26
12 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2020-05-26
12 Lars Eggert [Ballot Position Update] New position, Yes, has been recorded for Lars Eggert
2020-05-26
12 Laurent Ciavaglia
[Ballot comment]
Not being an expert in the field, I read the document from a high-level point of view.
The document is sufficiently well-written to …
[Ballot comment]
Not being an expert in the field, I read the document from a high-level point of view.
The document is sufficiently well-written to be understandable from a wide audience, and is clear in its goal.
Only a minor suggestion: when using "an adversary Adv", it may be better to put 'Adv' to avoid any confusion with another meaning or misspelling of a word or acronym.
2020-05-26
12 Laurent Ciavaglia [Ballot Position Update] New position, No Objection, has been recorded for Laurent Ciavaglia
2020-05-25
12 Allison Mankin
[Ballot comment]
I'm glad this document has progressed. My only comment is that it is a bit disorganized before it gets to the substance. It …
[Ballot comment]
I'm glad this document has progressed. My only comment is that it is a bit disorganized before it gets to the substance. It only states its purpose well in the abstract (which I often skip at first) and it describes two problems it will address: the issue of HSM not allowing a private key operation and the issue of length differences.On the length point, it says "previously discussed" but did not previously discuss it. So maybe a clarifying edit of the first couple pages would be good
2020-05-25
12 Allison Mankin [Ballot Position Update] New position, Yes, has been recorded for Allison Mankin
2020-05-25
12 Melinda Shore [Ballot comment]
Agree with Stephen about the title but don't see it as meriting objection.  Who knows - maybe it will generate broader interest?
2020-05-25
12 Melinda Shore [Ballot Position Update] New position, Yes, has been recorded for Melinda Shore
2020-05-25
12 Stephen Farrell
[Ballot comment]
I think this is a fine document. The only quibble I'd have is that the title is perhaps a bit too generic, compared …
[Ballot comment]
I think this is a fine document. The only quibble I'd have is that the title is perhaps a bit too generic, compared to the content.
2020-05-25
12 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2020-05-25
12 Marie-Jose Montpetit [Ballot comment]
My comments were addressed properly.
2020-05-25
12 Marie-Jose Montpetit [Ballot Position Update] New position, No Objection, has been recorded for Marie-Jose Montpetit
2020-05-25
12 Colin Perkins IRTF state changed to In IRSG Poll from Awaiting IRSG Reviews
2020-05-25
12 Colin Perkins Created IRSG Ballot
2020-05-25
12 Colin Perkins IRTF state changed to Awaiting IRSG Reviews from Waiting for Document Shepherd
2020-05-05
12 (System) Revised ID Needed tag cleared
2020-05-05
12 Christopher Wood New version available: draft-irtf-cfrg-randomness-improvements-12.txt
2020-05-05
12 (System) New version accepted (logged-in submitter: Christopher Wood)
2020-05-05
12 Christopher Wood Uploaded new revision
2020-05-05
11 Colin Perkins Previous comment was incorrect: this is waiting on update to address nits from IRSG review only.
2020-05-04
11 Colin Perkins Revision needed to clarify what is mandatory to implement, and to address review from Gwynne Raskind.
2020-05-04
11 Colin Perkins Tag IESG Review Completed cleared.
2020-05-04
11 Colin Perkins IRSG revised by Mallory Knodel and Marie-Jose Montpetit completed. Minor revision needed to address nits.
2020-05-04
11 Colin Perkins Tags IESG Review Completed, Revised I-D Needed set.
2020-05-04
11 Colin Perkins IRTF state changed to Waiting for Document Shepherd from Awaiting IRSG Reviews
2020-04-20
11 Colin Perkins IRTF state changed to Awaiting IRSG Reviews from Waiting for Document Shepherd
2020-04-14
11 (System) Revised ID Needed tag cleared
2020-04-14
11 Christopher Wood New version available: draft-irtf-cfrg-randomness-improvements-11.txt
2020-04-14
11 (System) New version accepted (logged-in submitter: Christopher Wood)
2020-04-14
11 Christopher Wood Uploaded new revision
2020-04-13
10 Colin Perkins The draft looks good – just needs a minor update to add the statements required by RFC 5743, Section 2.1, to the Introduction.
2020-04-13
10 Colin Perkins Tag Revised I-D Needed set.
2020-04-13
10 Colin Perkins IRTF state changed to Waiting for Document Shepherd from Waiting for IRTF Chair
2020-04-06
10 Colin Perkins Waiting on IRTF chair to review, before IRSG review.
2020-04-06
10 Colin Perkins IRTF state changed to Waiting for IRTF Chair from IRSG Review
2020-03-06
10 Alexey Melnikov Requesting publication as an RFC on behalf of CFRG.
2020-03-06
10 Alexey Melnikov IRTF state changed to IRSG Review from Waiting for Document Shepherd
2020-03-06
10 Alexey Melnikov
Technical Summary:

  Randomness is a crucial ingredient for TLS and related security
  protocols.  Weak or predictable "cryptographically-strong"
  pseudorandom number generators (CSPRNGs) can …
Technical Summary:

  Randomness is a crucial ingredient for TLS and related security
  protocols.  Weak or predictable "cryptographically-strong"
  pseudorandom number generators (CSPRNGs) can be abused or exploited
  for malicious purposes.  The Dual EC random number backdoor and
  Debian bugs are relevant examples of this problem.  An initial
  entropy source that seeds a CSPRNG might be weak or broken as well,
  which can also lead to critical and systemic security problems.  This
  document describes a way for security protocol participants to
  augment their CSPRNGs using long-term private keys.  This improves
  randomness from broken or otherwise subverted CSPRNGs.

Research Group Summary:

  The document was actively reviewed in CFRG and was presented
  at several face-to-face meetings. Comments were constructive
  but not particularly controversial. The document represents
  consensus of CFRG.

  There was a proposal to extend the document to cover constraint
  IOT cases, but CFRG decision was to do this work in a separate
  document.

  The document conforms to requirements from RFC 5743.

Document Quality:

  Interest in this work has been expressed by multiple parties
  at various points in time. In particular Apple, Cloudflare,
  and recently, the LAKE WG.

  There are at least two implementations in BoringSSL:
  one of which is public, the other is not.

Personnel:

  Alexey Melnikov is the document shepherd.
  Colin Perkins is the responsible IRTF Chair.
2020-02-17
10 Christopher Wood New version available: draft-irtf-cfrg-randomness-improvements-10.txt
2020-02-17
10 (System) New version accepted (logged-in submitter: Christopher Wood)
2020-02-17
10 Christopher Wood Uploaded new revision
2020-02-16
09 Alexey Melnikov
Technical Summary:

  Randomness is a crucial ingredient for TLS and related security
  protocols.  Weak or predictable "cryptographically-strong"
  pseudorandom number generators (CSPRNGs) can …
Technical Summary:

  Randomness is a crucial ingredient for TLS and related security
  protocols.  Weak or predictable "cryptographically-strong"
  pseudorandom number generators (CSPRNGs) can be abused or exploited
  for malicious purposes.  The Dual EC random number backdoor and
  Debian bugs are relevant examples of this problem.  An initial
  entropy source that seeds a CSPRNG might be weak or broken as well,
  which can also lead to critical and systemic security problems.  This
  document describes a way for security protocol participants to
  augment their CSPRNGs using long-term private keys.  This improves
  randomness from broken or otherwise subverted CSPRNGs.

Research Group Summary:

  The document was actively reviewed in CFRG and was presented
  at several face-to-face meetings. Comments were constructive
  but not particularly controversial. The document represents
  consensus of CFRG.

  There was a proposal to extend the document to cover constraint
  IOT cases, but CFRG decision was to do this work in a separate
  document.

  The document conforms to requirements from RFC 5743.

Document Quality:

 

 

Personnel:

  Alexey Melnikov is the document shepherd.
  Colin Perkins is the responsible IRTF Chair.
2020-02-16
09 Alexey Melnikov
Technical Summary:

  Randomness is a crucial ingredient for TLS and related security
  protocols.  Weak or predictable "cryptographically-strong"
  pseudorandom number generators (CSPRNGs) can …
Technical Summary:

  Randomness is a crucial ingredient for TLS and related security
  protocols.  Weak or predictable "cryptographically-strong"
  pseudorandom number generators (CSPRNGs) can be abused or exploited
  for malicious purposes.  The Dual EC random number backdoor and
  Debian bugs are relevant examples of this problem.  An initial
  entropy source that seeds a CSPRNG might be weak or broken as well,
  which can also lead to critical and systemic security problems.  This
  document describes a way for security protocol participants to
  augment their CSPRNGs using long-term private keys.  This improves
  randomness from broken or otherwise subverted CSPRNGs.

Research Group Summary:

  The document was actively reviewed in CFRG and was presented
  at several face-to-face meetings. Comments were constructive
  but not particularly controversial.

  There was a proposal to extend the document to cover constraint
  IOT cases, but CFRG decision was to do this work in a separate
  document.

Document Quality:

 

 

Personnel:

  Alexey Melnikov is the document shepherd.
  Colin Perkins is the responsible IRTF Chair.
2020-02-16
09 Alexey Melnikov
Technical Summary:

  Randomness is a crucial ingredient for TLS and related security
  protocols.  Weak or predictable "cryptographically-strong"
  pseudorandom number generators (CSPRNGs) can …
Technical Summary:

  Randomness is a crucial ingredient for TLS and related security
  protocols.  Weak or predictable "cryptographically-strong"
  pseudorandom number generators (CSPRNGs) can be abused or exploited
  for malicious purposes.  The Dual EC random number backdoor and
  Debian bugs are relevant examples of this problem.  An initial
  entropy source that seeds a CSPRNG might be weak or broken as well,
  which can also lead to critical and systemic security problems.  This
  document describes a way for security protocol participants to
  augment their CSPRNGs using long-term private keys.  This improves
  randomness from broken or otherwise subverted CSPRNGs.

Research Group Summary:

  The document was actively reviewed in CFRG and was presented
  at several face-to-face meetings. Comments were constructive
  but not particularly controversial.

  There was a proposal to extend the document to cover constraint
  IOT cases, but CFRG decision was to do this work in a separate
  document.

Document Quality:

 

Personnel:

  Alexey Melnikov is the document shepherd.
  Colin Perkins is the responsible IRTF Chair.
2020-02-16
09 Alexey Melnikov Intended Status changed to Informational from None
2020-02-16
09 Alexey Melnikov Notification list changed to Alexey Melnikov <alexey.melnikov@isode.com>
2020-02-16
09 Alexey Melnikov Document shepherd changed to Alexey Melnikov
2020-01-27
09 Christopher Wood New version available: draft-irtf-cfrg-randomness-improvements-09.txt
2020-01-27
09 (System) New version accepted (logged-in submitter: Christopher Wood)
2020-01-27
09 Christopher Wood Uploaded new revision
2019-11-02
08 Christopher Wood New version available: draft-irtf-cfrg-randomness-improvements-08.txt
2019-11-02
08 (System) New version accepted (logged-in submitter: Christopher Wood)
2019-11-02
08 Christopher Wood Uploaded new revision
2019-09-18
07 Alexey Melnikov IRTF state changed to Waiting for Document Shepherd from In RG Last Call
2019-09-07
07 Christopher Wood New version available: draft-irtf-cfrg-randomness-improvements-07.txt
2019-09-07
07 (System) New version approved
2019-09-07
07 (System) Request for posting confirmation emailed to previous authors: Luke Garratt , Cas Cremers , Stanislav Smyshlyaev , Christopher Wood , Nick Sullivan
2019-09-07
07 Christopher Wood Uploaded new revision
2019-07-08
06 Christopher Wood New version available: draft-irtf-cfrg-randomness-improvements-06.txt
2019-07-08
06 (System) New version approved
2019-07-08
06 (System)
Request for posting confirmation emailed to previous authors: Luke Garratt , Christopher Wood , cfrg-chairs@ietf.org, irtf-chair@irtf.org, Nick Sullivan , Stanislav Smyshlyaev , Cas …
Request for posting confirmation emailed to previous authors: Luke Garratt , Christopher Wood , cfrg-chairs@ietf.org, irtf-chair@irtf.org, Nick Sullivan , Stanislav Smyshlyaev , Cas Cremers
2019-07-08
06 Christopher Wood Uploaded new revision
2019-07-03
05 Alexey Melnikov Changed consensus to Yes from Unknown
2019-07-03
05 Alexey Melnikov IRTF state changed to In RG Last Call from Active RG Document
2019-06-01
05 Christopher Wood New version available: draft-irtf-cfrg-randomness-improvements-05.txt
2019-06-01
05 (System) New version approved
2019-06-01
05 (System) Request for posting confirmation emailed to previous authors: Luke Garratt , Stanislav Smyshlyaev , Christopher Wood , Cas Cremers , Nick Sullivan
2019-06-01
05 Christopher Wood Uploaded new revision
2019-03-11
04 Christopher Wood New version available: draft-irtf-cfrg-randomness-improvements-04.txt
2019-03-11
04 (System) New version approved
2019-03-11
04 (System) Request for posting confirmation emailed to previous authors: Luke Garratt , Stanislav Smyshlyaev , Christopher Wood , Cas Cremers , Nick Sullivan
2019-03-11
04 Christopher Wood Uploaded new revision
2018-11-03
03 Alexey Melnikov Added to session: IETF-103: cfrg  Mon-1120
2018-10-31
03 Alexey Melnikov This document now replaces draft-sullivan-randomness-improvements, draft-cremers-cfrg-randomness-improvements instead of draft-sullivan-randomness-improvements
2018-10-21
03 Stanislav Smyshlyaev New version available: draft-irtf-cfrg-randomness-improvements-03.txt
2018-10-21
03 (System) New version approved
2018-10-21
03 (System) Request for posting confirmation emailed to previous authors: Luke Garratt , Stanislav Smyshlyaev , Christopher Wood , Cas Cremers , Nick Sullivan
2018-10-21
03 Stanislav Smyshlyaev Uploaded new revision
2018-07-15
02 Stanislav Smyshlyaev New version available: draft-irtf-cfrg-randomness-improvements-02.txt
2018-07-15
02 (System) New version approved
2018-07-15
02 (System) Request for posting confirmation emailed to previous authors: Luke Garratt , Stanislav Smyshlyaev , Christopher Wood , Cas Cremers , Nick Sullivan
2018-07-15
02 Stanislav Smyshlyaev Uploaded new revision
2018-07-11
01 Alexey Melnikov Added to session: IETF-102: cfrg  Tue-1550
2018-07-02
01 Nick Sullivan New version available: draft-irtf-cfrg-randomness-improvements-01.txt
2018-07-02
01 (System) New version approved
2018-07-02
01 (System) Request for posting confirmation emailed to previous authors: Luke Garratt , Stanislav Smyshlyaev , Christopher Wood , Cas Cremers , Nick Sullivan
2018-07-02
01 Nick Sullivan Uploaded new revision
2018-04-08
00 Alexey Melnikov IRTF state changed to Active RG Document
2018-04-08
00 Alexey Melnikov This document now replaces draft-sullivan-randomness-improvements instead of None
2018-03-23
00 Christopher Wood New version available: draft-irtf-cfrg-randomness-improvements-00.txt
2018-03-23
00 (System) WG -00 approved
2018-03-23
00 Christopher Wood Set submitter to ""Christopher A. Wood" ", replaces to (none) and sent approval email to group chairs: cfrg-chairs@ietf.org
2018-03-23
00 Christopher Wood Uploaded new revision