idnits 2.17.1 draft-moskowitz-orchid-cshake-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7343]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (11 December 2019) is 1598 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-moskowitz-hip-hierarchical-hit-02 == Outdated reference: A later version (-10) exists of draft-moskowitz-hip-new-crypto-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP R. Moskowitz 3 Internet-Draft HTT Consulting 4 Intended status: Standards Track S. Card 5 Expires: 13 June 2020 A. Wiethuechter 6 AX Enterprize 7 11 December 2019 9 Using cSHAKE in ORCHIDs 10 draft-moskowitz-orchid-cshake-00 12 Abstract 14 This document specifies how to use the cSHAKE hash for ORCHID 15 generation and allows for varying sized hashes in the ORCHID along 16 with additional information within the ORCHID. It is an addendum to 17 ORCHIDv2 [RFC7343]. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 13 June 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 2 54 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 55 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Adding additional information to the ORCHID . . . . . . . . . 3 58 4. ORCHID Decoding . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. ORCHID Encoding . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Initial use case for cSHAKE . . . . . . . . . . . . . . . . . 5 61 7. Initial use case for Additional Information . . . . . . . . . 5 62 8. Collision risks with Hierarchical HITs . . . . . . . . . . . 6 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 12.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 12.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Appendix A. Calculating Collision Probabilities . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 This document adds the [Keccak] based cSHAKE XOF hash function from 75 NIST SP 800-185 [NIST.SP.800-185] to ORCHIDv2 [RFC7343]. cSHAKE is a 76 variable output length hash function. As such it does not need the 77 truncation operation that other hashes need. The invocation of 78 cSHAKE specifies the desired number of bits in the hash output. 80 cSHAKE is used, rather than SHAKE from NIST FIPS 202 [NIST.FIPS.202], 81 as cSHAKE has a parameter 'S' as a customization bit string. This 82 parameter will be used for including the ORCHID Context Identifier in 83 a standard fashion. 85 An additional change to ORCHID construction will allow for shorter 86 hash output lengths to permit inclusion of additional information 87 like Hierarchical HITs [I-D.moskowitz-hip-hierarchical-hit] into the 88 ORCHID. 90 2. Terms, Notation and Definitions 91 2.1. Requirements Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in BCP 96 14 [RFC2119] [RFC8174] when, and only when, they appear in all 97 capitals, as shown here. ` 99 2.2. Notation 101 | Signifies concatenation of information - e.g., X | Y is the 102 concatenation of X and Y. 104 2.3. Definitions 106 Keccak (KECCAK Message Authentication Code): 107 The family of all sponge functions with a KECCAK-f permutation as 108 the underlying function and multi-rate padding as the padding 109 rule. 111 cSHAKE (The customizable SHAKE function): 112 Extends the SHAKE scheme to allow users to customize their use of 113 the function. 115 SHAKE (Secure Hash Algorithm KECCAK): 116 A secure hash that allows for an arbitrary output length. 118 XOF (eXtendable-Output Function): 119 A function on bit strings (also called messages) in which the 120 output can be extended to any desired length. 122 3. Adding additional information to the ORCHID 124 ORCHIDv2 [RFC7343] is currently defined as consisting of three 125 components: 127 ORCHID := Prefix | OGA ID | Encode_96( Hash ) 129 where: 131 Prefix : A constant 28-bit-long bitstring value 132 (IANA IPv6 assigned). 134 OGA ID : A 4-bit long identifier for the Hash_function 135 in use within the specific usage context. 137 Encode_96( ) : An extraction function in which output is obtained 138 by extracting the middle 96-bit-long bitstring 139 from the argument bitstring. 141 This addendum will be constructed as follows: 143 ORCHID := Prefix | OGA ID | Info (n) | Hash (m) 145 where: 147 Prefix : A constant 28-bit-long bitstring value 148 (IANA IPv6 assigned). 150 OGA ID : A 4-bit long identifier for the Hash_function 151 in use within the specific usage context. 153 Info (n) : n bits of information that define a use of the 154 ORCHID n can be zero, that is no additional 155 information. 157 Hash (m) : An extraction function in which output is m bits. 159 n + m = 96 bits 161 The 96 bits currently allocated to the Encode_96 function can be 162 divided in any manner between the additional information and the hash 163 output. Care must be taken in determining the size of the hash 164 portion, taking into account risks like pre-image attacks. Thus 64 165 bits as used in Hierarchical HITs may be as small as is acceptable. 167 4. ORCHID Decoding 169 With this addendum, the decoding of an ORCHID is determined by the 170 Prefix and OGA ID. ORCHIDv2 [RFC7343] decoding is selected when the 171 Prefix is: 2001:20::/28. 173 For Heirarchical HITs, the decoding is determined by the presence of 174 the HHIT Prefix as specified in the HHIT document. 176 5. ORCHID Encoding 178 ORCHIDv2 has a number of inputs including a Context ID, some header 179 bits, the hash algorithm, and the input bitstream, normally just the 180 public key. The output is a 96 bit value. 182 This addendum adds a different encoding process to that currently 183 used. The input to the hash function explicitly includes all the 184 fixed header content plus the Context ID. The fixed header content 185 consists of the Prefix, OGA ID, and the Additional Information. 186 Secondly, the length of the resulting hash is set by the rules set by 187 the Prefix/OGA ID. In the case of Hierarchical HITs, this is 64 188 bits. 190 To achieve the variable length output in a consistent manner, the 191 cSHAKE hash is used. For this purpose, cSHAKE128 is appropriate. 192 The the cSHAKE function call for this addendum is: 194 cSHAKE128(Input, L, "", Context ID) 196 Input := Prefix | OGA ID | Additional Information | HOST_ID 197 L := Length in bits of hash portion of ORCHID 199 Hierarchical HIT uses the same context as all other HIPv2 HIT Suites 200 as they are clearly separated by the distinct HIT Suite ID. 202 6. Initial use case for cSHAKE 204 The EdDSA/cSHAKE based HITs in New Cryptographic Algorithms for HIP 205 [I-D.moskowitz-hip-new-crypto] is the first HIP Suite to use cSHAKE, 206 thus using this addendum. 208 7. Initial use case for Additional Information 210 Hierarchical HITs [I-D.moskowitz-hip-hierarchical-hit] (HHITs) is the 211 first HIT construct that specifies the need of dividing the 96 bits 212 available to ORCHID into its Hierarchy ID (HID) and HI Hash, thus 213 using this addendum. 215 HHITs use a unique Context ID as well as a Prefix different from 216 HIPv2 [RFC7401]. The different Prefix enables receivers to properly 217 decode the HID out of the HIT and validate the HIT, given the HI. 219 8. Collision risks with Hierarchical HITs 221 The 64 bit hash size does have an increased risk of collisions over 222 the 96 bit hash size used for the other HIT Suites. There is a 0.01% 223 probability of a collision in a population of 66 million. The 224 probability goes up to 1% for a population of 663 million. See 225 Appendix A for the collision probability formula. 227 However, this risk of collision is within a single "Additional 228 Information" value. Some registration process should be used to 229 reject a collision, forcing the client to generate a new HI and thus 230 HIT and reapplying to the registration process. 232 9. IANA Considerations 234 TBD. 236 10. Security Considerations 238 A 64 bit hash space presents a real risk of second pre-image attacks. 239 A Registry service effectively block attempts to "take over" such a 240 HIT. It does not stop a rogue attempting to impersonate a known HIT. 241 This attack can be mitigated by the Responder using DNS to find the 242 HI for the HIT or the RVS for the HIT that then provides the 243 registered HI. 245 11. Acknowledgments 247 Quynh Dang of NIST gave considerable guidance on using Keccak and the 248 NIST supporting documents. Joan Deamen of the Keccak team was 249 especially helpful in many aspects of using Keccak. 251 12. References 253 12.1. Normative References 255 [NIST.FIPS.202] 256 Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 257 Extendable-Output Functions", DOI 10.6028/nist.fips.202, 258 National Institute of Standards and Technology report, 259 July 2015, . 261 [NIST.SP.800-185] 262 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 263 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 264 DOI 10.6028/nist.sp.800-185, National Institute of 265 Standards and Technology report, December 2016, 266 . 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, 270 DOI 10.17487/RFC2119, March 1997, 271 . 273 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 274 Routable Cryptographic Hash Identifiers Version 2 275 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 276 2014, . 278 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 279 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 280 May 2017, . 282 12.2. Informative References 284 [I-D.moskowitz-hip-hierarchical-hit] 285 Moskowitz, R., Card, S., and A. Wiethuechter, 286 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 287 Draft, draft-moskowitz-hip-hierarchical-hit-02, 17 October 288 2019, . 291 [I-D.moskowitz-hip-new-crypto] 292 Moskowitz, R., Card, S., and A. Wiethuechter, "New 293 Cryptographic Algorithms for HIP", Work in Progress, 294 Internet-Draft, draft-moskowitz-hip-new-crypto-02, 3 295 October 2019, . 298 [Keccak] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., and 299 R. Van Keer, "The Keccak Function", 300 . 302 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 303 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 304 RFC 7401, DOI 10.17487/RFC7401, April 2015, 305 . 307 Appendix A. Calculating Collision Probabilities 309 The accepted formula for calculating the probability of a collision 310 is: 312 p = 1 - e^{-k^2/(2n)} 314 P Collision Probability 315 n Total possible population 316 k Actual population 318 Authors' Addresses 320 Robert Moskowitz 321 HTT Consulting 322 Oak Park, MI 48237 323 United States of America 325 Email: rgm@labs.htt-consult.com 327 Stuart W. Card 328 AX Enterprize 329 4947 Commercial Drive 330 Yorkville, NY 13495 331 United States of America 333 Email: stu.card@axenterprize.com 335 Adam Wiethuechter 336 AX Enterprize 337 4947 Commercial Drive 338 Yorkville, NY 13495 339 United States of America 341 Email: adam.wiethuechter@axenterprize.com