Randomness Improvements for Security Protocols
RFC 8937

Document Type RFC - Informational (October 2020; No errata)
Authors Cas Cremers  , Luke Garratt  , Stanislav Smyshlyaev  , Nick Sullivan  , Christopher Wood 
Last updated 2020-10-17
Replaces draft-sullivan-randomness-improvements, draft-cremers-cfrg-randomness-improvements
Stream IRTF
Formats plain text html xml pdf htmlized bibtex
IETF conflict review conflict-review-irtf-cfrg-randomness-improvements
Stream IRTF state Published RFC
Consensus Boilerplate Yes
Document shepherd Alexey Melnikov
Shepherd write-up Show (last changed 2020-03-06)
IESG IESG state RFC 8937 (Informational)
Telechat date
Responsible AD (None)
Send notices to Alexey Melnikov <alexey.melnikov@isode.com>
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions

Internet Research Task Force (IRTF)                           C. Cremers
Request for Comments: 8937                                         CISPA
Category: Informational                                       L. Garratt
ISSN: 2070-1721                                             Cisco Meraki
                                                           S. Smyshlyaev
                                                             N. Sullivan
                                                                 C. Wood
                                                            October 2020

             Randomness Improvements for Security Protocols


   Randomness is a crucial ingredient for Transport Layer Security (TLS)
   and related security protocols.  Weak or predictable
   "cryptographically secure" pseudorandom number generators (CSPRNGs)
   can be abused or exploited for malicious purposes.  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 implementations to
   augment their CSPRNGs using long-term private keys.  This improves
   randomness from broken or otherwise subverted CSPRNGs.

   This document is a product of the Crypto Forum Research Group (CFRG)
   in the IRTF.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Research Task Force
   (IRTF).  The IRTF publishes the results of Internet-related research
   and development activities.  These results might not be suitable for
   deployment.  This RFC represents the consensus of the Crypto Forum
   Research Group of the Internet Research Task Force (IRTF).  Documents
   approved for publication by the IRSG are not a candidate for any
   level of Internet Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1.  Introduction
   2.  Conventions Used in This Document
   3.  Randomness Wrapper
   4.  Tag Generation
   5.  Application to TLS
   6.  Implementation Guidance
   7.  IANA Considerations
   8.  Security Considerations
   9.  Comparison to RFC 6979
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Authors' Addresses

1.  Introduction

   Secure and properly implemented random number generators, or
   "cryptographically secure" pseudorandom number generators (CSPRNGs),
   should produce output that is indistinguishable from a random string
   of the same length.  CSPRNGs are critical building blocks for TLS and
   related transport security protocols.  TLS in particular uses CSPRNGs
   to generate several values, such as ephemeral key shares and
   ClientHello and ServerHello random values.  CSPRNG failures, such as
   the Debian bug described in [DebianBug], can lead to insecure TLS
   connections.  CSPRNGs may also be intentionally weakened to cause
   harm [DualEC].  Initial entropy sources can also be weak or broken,
   and that would lead to insecurity of all CSPRNG instances seeded with
   them.  In such cases where CSPRNGs are poorly implemented or
   insecure, an adversary, Adv, may be able to distinguish its output
   from a random string or predict its output and recover secret key
   material used to protect the connection.

   This document proposes an improvement to randomness generation in
   security protocols inspired by the "NAXOS trick" [NAXOS].
   Specifically, instead of using raw randomness where needed, e.g., in
   generating ephemeral key shares, a function of a party's long-term
   private key is mixed into the entropy pool.  In the NAXOS key
   exchange protocol, raw random value x is replaced by H(x, sk), where
   sk is the sender's private key.  Unfortunately, as private keys are
   often isolated in Hardware Security Modules (HSMs), direct access to
   compute H(x, sk) is impossible.  Moreover, some HSM APIs may only
   offer the option to sign messages using a private key, yet offer no
   other operations involving that key.  An alternate, yet functionally
   equivalent construction, is needed.

   The approach described herein replaces the NAXOS hash with a keyed
Show full document text