idnits 2.17.1 draft-sullivan-randomness-improvements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Cramers 3 Internet-Draft L. Garratt 4 Intended status: Informational University of Oxford 5 Expires: May 3, 2018 N. Sullivan 6 Cloudflare 7 October 30, 2017 9 Randomness Improvements for Security Protocols 10 draft-sullivan-randomness-improvements-00 12 Abstract 14 Randomness is a crucial ingredient for TLS and related transport 15 security protocols. Weak or predictable cryptographically-strong 16 pseudorandom number generators (CSPRNGs) can be abused or exploited 17 for malicious purposes. See the Dual EC random number backdoor for a 18 relevant example of this problem. This document describes a way for 19 security protocol participants to mix their long-term private key 20 into the entropy pool from which random values are derived. This may 21 help mitigate problems that stem from broken CSPRNGs. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 3, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Randomness Wrapper . . . . . . . . . . . . . . . . . . . . . 2 59 3. Application to TLS . . . . . . . . . . . . . . . . . . . . . 3 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 65 1. Introduction 67 Randomness is a crucial ingredient for TLS and related transport 68 security protocols. TLS in particular uses Random Number Generators 69 (RNGs) to generate several values: session IDs, ephemeral key shares, 70 and ClientHello and ServerHello random values. RNG failures such as 71 the Debian bug described in [DebianBug] can lead to insecure TLS 72 connections. RNGs may also be intentionally weakened to cause harm 73 [DualEC]. In such cases where RNGs are poorly implemented or 74 insecure, an adversary may be able to predict its output and recover 75 secret Diffie-Hellman key shares that protect the connection. 77 This document proposes an improvement to randomness generation in 78 security protocols inspired by the "NAXOS trick" [NAXOS]. 79 Specifically, instead of using raw entropy where needed, e.g., in 80 generating ephemeral key shares, a party's long-term private key is 81 mixed into the entropy pool. In the NAXOS key exchange protocol, raw 82 entropy output x is replaced by H(x, sk), where sk is the sender's 83 private key. Unfortunately, as private keys are often isolated in 84 HSMs, direct access to compute H(x, sk) is impossible. An alternate 85 but functionally equivalent construction is needed. 87 The approach described herein replaces the NAXOS hash with the keyed 88 hash, or PRF, wherein the key is derived from raw entropy output and 89 a private key signature. 91 2. Randomness Wrapper 93 Let x be the raw entropy output of a CSPRNG. When properly 94 instantiated, x should be indistinguishable from a random string of 95 length |x|. However, as previously discussed, this is always true. 96 To mitigate this problem, we propose an approach for wrapping the 97 CSPRNG output with a construction that artificially injects 98 randomness into a value that may be lacking entropy. 100 Let PRF(k, m) be a cryptographic pseudorandom function, e.g., HMAC 101 [RFC2104], that takes as input a key k of length L and message m and 102 produces an output of length M. For example, when using HMAC with 103 SHA256, L and M are 256 bits. Let Sig(sk, m) be a function that 104 computes a signature of message m given private key sk. Let G be an 105 algorithm that generates random numbers from raw entropy, i.e., the 106 output of a CSPRNG. Let tag be a fixed, context-dependent string. 107 Lastly, let KDF be a key derivation function, e.g., HKDF-Extract 108 [RFC5869], that extracts a key of length L suitable for cryptographic 109 use. 111 The construction is simple: instead of using x when randomness is 112 needed, use: 114 PRF(KDF(G(x) || Sig(sk, tag)), tag) 116 Functionally, this computes the PRF of a fixed string with a key 117 derived from the CSPRNG output and signature over the fixed string. 118 The PRF behaves like a truly random function from 2^L to 2^M assuming 119 the key is selected at random. Thus, the security of this 120 construction depends on secrecy of Sig(sk, tag) and G(x). If both 121 are leaked, then the security reduces to the scenario wherein this 122 wrapping construction is not applied. 124 In systems where signature computations are not cheap, these values 125 may be precomputed in anticipation of future randomness requests. 126 This is possible since the construction depends solely upon the 127 CSPRNG output and private key. 129 3. Application to TLS 131 The PRF randomness wrapper can be applied to any protocol wherein a 132 party has a long-term private key and also generates randomness. 133 This is true of most TLS servers. Thus, to apply this construction 134 to TLS, one simply replaces the "private" PRNG, i.e., the PRNG that 135 generates private values, such as key shares, with: 137 HMAC(HKDF-Extract(nil, G(x) || Sig(sk, tag)), tag) 139 Moreover, we fix tag as "TLS 1.3 Additional Entropy" for TLS 1.3. 140 Older variants use similarly constructed strings. 142 4. IANA Considerations 144 This document makes no request to IANA. 146 5. Security Considerations 148 A security analysis was performed by two authors of this document. 149 Generally speaking, security depends on keeping the private key 150 secret. If this secret is compromised, the scheme reduces to the 151 scenario wherein the PRF random wrapper was not applied in the first 152 place. 154 6. Normative References 156 [DebianBug] 157 Yilek, Scott, et al, ., "When private keys are public - 158 Results from the 2008 Debian OpenSSL vulnerability", n.d., 159 . 162 [DualEC] Bernstein, Daniel et al, ., "Dual EC - A standardized back 163 door", n.d., . 166 [NAXOS] LaMacchia, Brian et al, ., "Stronger Security of 167 Authenticated Key Exchange", n.d., 168 . 171 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 172 Hashing for Message Authentication", RFC 2104, 173 DOI 10.17487/RFC2104, February 1997, 174 . 176 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 177 Key Derivation Function (HKDF)", RFC 5869, 178 DOI 10.17487/RFC5869, May 2010, 179 . 181 Authors' Addresses 183 Cas Cremers 184 University of Oxford 185 Wolfson Building, Parks Road 186 Oxford 187 England 189 Email: cas.cremers@cs.ox.ac.uk 190 Luke Garratt 191 University of Oxford 192 Wolfson Building, Parks Road 193 Oxford 194 England 196 Email: luke.garratt@wolfson.ox.ac.uk 198 Nick Sullivan 199 Cloudflare 200 101 Townsend St 201 San Francisco 202 United States of America 204 Email: nick@cloudflare.com